cid номер что это
Настройка входящей маршрутизации (входящих вызовов) на АТС 3CX Phone System. DID- и CID-правила.
Самая простая настройка входящей маршрутизации – это настройка на самом транке. В основной вкладке в разделе Направление вызовов нужно указать на какой добавочный номер или сервис АТС будет приземляться звонок в рабочее и нерабочее время.
Кроме такого простого варианта 3CX позволяет задавать уникальную входящую маршрутизацию в зависимости от номера, на который позвонили (DID-правила), и в зависимости от номера, с которого пришел вызов (CID-правила).
DID-правила
Часто оператор связи, когда предоставляет несколько (много) городских номеров, подает их на один транк (обычно такой транк предоставляется с идентификацией по ip-адресу). В большинстве случаев это намного удобнее, нежели для каждого городского номера предоставлять отдельный транк. Когда набор городских номеров заводится на один транк, почти всегда встает задача различной входящей маршрутизации в зависимости от того, на какой номер пришел вызов.
Для настройки такой маршрутизации вначале необходимо в свойствах транка перечислить DID-номера, т.е. номера, которые оператор связи вам предоставил на данном транке. Для этого нужно в свойствах транка переключиться на вкладку DID и в ней добавить необходимые номера.
Эта вкладка уже изначально в качестве первого DID-номера содержит основной номер транка (описание этой опции читайте в статье, посвященной базовой настройке транка). Ваша задача добавить остальные номера.
Вы можете добавлять, как номера, состоящие из полного набора цифр, так и шаблоны номеров. В шаблоне можно либо в начале номера, либо в его конце, указать символ *. Это будет обозначать, что вместо * в номере может идти произвольный набор цифр. Такой прием удобен, если вы хотите для группы номеров, имеющих одинаковую общую часть, задать единую входящую маршрутизацию.
После того, как на транке прописаны все DID-номера (шаблоны), можно переходить к непосредственному созданию и редактированию DID-правил. Это делается в веб-панели администрирования 3CX в разделе Входящие правила. Для создания правила нужно нажать на кнопку «+Добавить правило DID».
В открывшемся окне настроек необходимо в списке DID/DDI выбрать нужный и ранее созданный DID-номер или DID-шаблон и для этого номера/шаблона определить входящую маршрутизацию для рабочих и нерабочих часов.
Поле Название правила является опциональным. Его задавать не обязательно. Если вы зададите название, то при входящем вызове на телефоне перед именем/номером позвонившего или после имени/номера будет выводиться название правила, согласно которому на ваш телефон был маршрутизирован вызов. В большинстве случаев такое удобно – видеть на какой номер пришел звонок. Наша рекомендация: не делайте название правила длинным, иначе будет проблематично его отобразить на телефоне вместе с именем/номером позвонившего.
Чтоб настроить в каком месте нужно отображать название правила (до или после имени/номера позвонившего), в веб-панели администрирования 3CX перейдите в раздел Контакты и справа вверху нажмите на кнопку «Параметры». Нужная опция находится внизу, в разделе Добавить название Группы, Очереди или DID/DDI к Caller ID.
Для 3CX важно в какой последовательности идут DID- и CID-правила. Когда приходит входящий вызов, 3CX начинает последовательно сверху вниз просматривать входящие правила, и будет применено первое подходящее. Обычно CID-правила располагают выше DID-правил, т.к. в противном DID-правила, как правила более широкого толка, не дадут возможности сработать CID-правилам (правилам, основанным на номере, с которого позвонили). А вот в обратной ситуации, приоритетные CID-правила в общем случае не будут блокировать DID-правила.
Если при входящем звонке 3CX не нашла для него ни одного DID/CID-правила, входящая маршрутизация будет отработана по настройкам sip-транка, принявшего звонок. Эти настройки находятся в свойствах транка, вкладка Основные, раздел Направление вызовов.
СID-правила
Настройка CID-правил (основанных на номере, с которого пришел вызов) почти полностью аналогична настройке DID-правил. Только в случае с CID-правилами номер или его маска задаются непосредственно в самом правиле – внутри транка CID-номера прописывать не нужно. И второе отличие: в CID-правиле нужно указывать, для какого транка оно будет работать. Надо понимать, что невозможно создать CID-правило, которое будет задавать маршрутизацию только исходя из условия с какого номера пришел вызов, и не важно на какой транк. CID-правило это обязательно и номер позвонившего, и транк, на который пришел вызов.
* Если мы не смогли полно ответить на ваш вопрос, или вы искали другую информацию, которой нет в нашей базе знаний, обращайтесь в нашу компанию по телефону или по e-mail. Обращаем внимание: для всех новых клиентов, которые находятся на стадии изучения 3CX и определяются с покупкой, мы предлагаем полностью бесплатную поддержку, а для коммерческих инсталляций действует лояльная ценовая политика. Более подробно читайте по ссылке.
Найти и обезвредить. Как раскрыть местоположение мобильного абонента
В сетях мобильной связи возможно осуществление довольно специфичных атак. Об одной из них — раскрытии местоположения абонента в реальном времени с точностью до определения соты — пойдет речь в данной статье. Я не указываю точность в более привычных единицах измерения, т. к. размер соты не является величиной постоянной. В плотных городских застройках сота может обеспечивать покрытие порядка сотен метров, а в условиях лесов, полей и рек междугородной трассы — нескольких километров.
Элементы системы
Рисунок 1 (по клику открывается в полном размере)
Для начала проведу небольшое введение в структуру сотовой сети на примере стандарта GSM. Упрощенная схема стандарта приведена на рисунке 1.
Покрытие обеспечивается базовыми станциями (Base Station, BS), каждая из которых, как правило, имеет несколько антенн, направленных в разные стороны. Антенна обеспечивает радиопокрытие соты, каждая сота имеет свой идентификатор (Cell Identity, CI). Базовые станции группируются в географические зоны (Location Area, LA). Группировка происходит чаще всего по территориальному принципу. Идентификатор такой группы называется LAC (Location Area Code). На рисунке 1 каждая базовая станция обеспечивает покрытие трех секторов.
Базовые станции подсоединяются к контроллеру базовых станций (Base Station Controller, BSC). В самом простом варианте один LAC соответствует одному BSC. Именно такое назначение LAC показано на примере (рисунок 1). Для наглядности LAC выделены разными цветами.
Территория, покрываемая одним LAC, зависит от плотности населения. В Москве, в пределах МКАД, может быть несколько десятков LAC, а в небольшом регионе центральной полосы России разделение на LAC может быть таким: один LAC покрывает областной центр, второй LAC покрывает всю остальную территорию области.
Все контроллеры BSC подключаются к коммутатору (Mobile Switching Center, MSC). По сути, MSC представляет собой обычный коммутатор голосовых телефонных вызовов с аппаратно-программным расширением для обеспечения функций мобильности абонентов. В эпоху широкого распространения IP следует напомнить, что MSC оперирует коммутацией цепей (Circuit Switched) согласно установленным в нем статичным таблицам маршрутизации на основе привычной нам телефонной нумерации.
Регистр местоположения визитных абонентов (Visited Location Register, VLR) функционально считается отдельным элементом сети, но фактически всегда интегрирована с MSC. В базе данных VLR содержится информация об абонентах, которые в данный момент находятся в зоне действия своего MSC. И раз уж тема статьи о местоположении абонента, то стоит упомянуть, что для каждого абонента в БД VLR хранится информация о текущем идентификаторе LAC, и идентификаторе той соты (CI), которая была при последнем радиоконтакте мобильного телефона с сетью. То есть, если абонент передвигается по территории покрытия одного LAC, не совершая и не принимая вызовов, в базе данных VLR информация о его местоположении не меняется. В общем случае, в сети может быть несколько узлов MSC/VLR. В примере на рисунке 1 показано два таких узла.
Еще два функциональных узла — регистр местоположения домашних абонентов (Home Location Register, HLR) и центр аутентификации (Authentication Center, AuC) — размещаются физически в едином модуле. HLR/AuC хранит профили абонентов своей сети. В профиле содержится следующая информация: телефонный номер абонента, уникальный идентификатор SIM-карты (International Mobile Subscriber Identity, IMSI), ключи для обеспечения безопасности, категория абонента (предоплатная система расчетов /постоплатная система расчетов), список разрешенных и запрещенных услуг, адрес биллинг-центра (для абонентов предоплатной системы), адрес MSC/VLR, в зоне действия которого находится абонент в настоящий момент. Этот же профиль с некоторыми изменениями копируется в VLR, когда абонент регистрируется в зоне его действия.
Шлюзовой коммутатор (Gateway MSC, GMSC) является приемной точкой для входящих вызовов. Он на основе информации, полученной из HLR, маршрутизирует вызов на тот коммутатор, в зоне действия которого находится вызываемый абонент.
В процессе установления вызова, отправки SMS и прочих транзакций, узлы связи обмениваются между собой сигнальными сообщениями. Стек протоколов, набор сообщений и их параметров в сетях телефонной (не только мобильной) связи называется Системой сигнализации №7 (Signaling System 7, SS7). Все протоколы SS7 открыты и доступны для ознакомления и изучения на сайтах таких международных организаций, как МСЭ-Т, 3GPP, GSMA. Описанная далее атака опирается на сообщения SS7.
Атака
Разумеется, данную атаку не сможет совершить любой человек с улицы. Для осуществления атаки звезды должны расположиться в правильном порядке на небосводе. А именно:
Рисунок 2 (по клику открывается в полном размере)
1. Мобильный телефон регистрируются в сети одного из украинских мобильных операторов. В какой-то момент абонент входит в зону покрытия LAC 41800 со стороны сектора CI 22C0 и продолжает движение вплоть до сектора CI 22CF. Что же в это время происходит в сети оператора? Когда телефон оказывается в зоне покрытия LAC 41800, то инициируется процедура Location Update, обновляя в базе данных VLR значения LAC и CI. По мере движения нашего коллеги до сектора CI 22CF в базе данных VLR не происходит более никаких изменений.
2. Мы хотим узнать, на самом ли деле у наших сотрудников идут сложные переговоры. И в какой-то момент мы формируем SMS-сообщение с атрибутом Type-0 и отправляем на номер одного из коллег. Напоминаю, что по легенде он в это время находится в секторе CI 22CF.
3. У SMS-сообщения Type-0 есть другое название — SMS-пинг. Это сообщение не отображается на экране мобильного телефона и не сохраняется в списке принятых SMS. Кроме того, оно осуществляет действия, которые абонент не планировал, а именно, производит обновление атрибутов местоположения в базе данных VLR. Теперь в VLR хранится актуальное значение сектора, в котором прибывает абонент, то есть CI 22CF.
4. Мы уже начали свою активность, однако еще не получили ни байта результата. Информация о местоположении абонента хоть и обновилась, но она находится в недрах оборудования оператора, и чтобы выудить данные, мы продолжаем наши исследования. На следующем шаге формируем сигнальное сообщение sendRoutingInfoForSM, где в качестве параметра указывается мобильный номер нашего сотрудника, и отправляем это сообщение на HLR оператора.
5. В мире телекома принято доверять друг другу, особенно запросам, пришедшим по сетям SS7, и HLR оператора не является исключением из этого правила. На рисунке 3 показана выдержка из трассировки. HLR находит в своих базах данных идентификатор IMSI абонента (1) и адрес MSC/VLR (2), в зоне действия которого находится абонент с заданным номером, и, не подозревая подвоха, сообщает своему «собеседнику» эти данные. Здесь можно обратить внимание на значения некоторых цифр. Первые три цифры идентификатора IMSI обозначают код страны абонента (Mobile Country Code, MCC). Код 250 закреплен за Россией (1). Адрес коммутатора предоставляется в более привычной для нас телефонной нумерации, где 380 — международный телефонный код Украины (2).
На этом шаге можно сделать небольшую паузу. Дело в том, что в сети существуют сервисы, которые на этом останавливаются и выдают своим пользователям информацию о местоположении любого мобильного абонента с точностью до мобильного коммутатора.
На рисунке 4 показан фрагмент скриншота с результатами поиска того же самого человека. Тут мы видим номер абонента (1). Кроме того, сервис раскрывает идентификатор IMSI (2), который вообще-то является конфиденциальной информацией и должен храниться оператором за семью печатями. Следом нам показан номер сервис-центра, где находится абонент (3). Фактически это урезанный адрес мобильного коммутатора. В России по номеру сервис-центра можно определить регион нахождения абонента, т. к. адресация коммутаторов совпадает с региональной телефонной нумерацией. К сожалению, для украинских мобильных операторов мне не удалось найти такого соответствия.
6. Наши поиски продолжаются. Теперь мы формируем сообщение provideSubscriberInfo, где в качестве параметра задаем идентификатор IMSI, и отправляем это сообщение на адрес мобильного коммутатора. Все нужные параметры (IMSI и адрес MSC/VLR) мы получили на предыдущем шаге.
7. И опять мы сыграем на всеобщем доверии. Коммутатор воспринимает сообщение как вполне легальное и с удовольствием сообщает в ответ идентификаторы сети MCC/MNC, значение LAC и недавно обновленное значение сектора CI.
Теперь посмотрим на трассировку (рисунок 5). Все значения, нужные нам для пеленгации, получены:
Пока это только набор цифр, из которого мы сможем узнать страну по MCC — код 255 закреплен за Украиной. Пока все сходится. Для финального выстрела открываем сервис для определения координат базовой станции, коих в сети можно найти немало (рисунок 6). И что же мы видим? Это не Киев, а Феодосия, причем сектор обслуживает не городскую черту, а морское побережье с пляжами! Теперь ясно, чем наши коллеги так долго заняты в командировке 🙂
Заключение
В качестве пользователей описанного в статье «сервиса» можно представить криминальных элементов, промышленных шпионов, частных детективов… Но остается вопрос: кто и каким образом может реализовать подобного рода атаки?
В первую очередь, такая возможность есть у технических специалистов операторов связи, причем сам оператор может находиться в любой стране мира.
Во-вторых, для реализации сервиса может быть специально создана компания с получением необходимых лицензий, закупкой оборудования и подключением к SS7 обязательно с возможностью работы протокола MAP. Денежные затраты на реализацию такого варианта в России будут исчисляться круглыми суммами и вряд ли смогут окупиться.
Третий вариант — взлом сети управления оператора и внедрение «жучка» в его существующую инфраструктуру.
А у правоохранительных органов имеются свои средства оперативно-розыскных мероприятий (СОРМ), в том числе с функцией поиска местоположения.
Автор: Сергей Пузанков, исследовательский центр Positive Research.
P. S. Хочу выразить благодарность отделу анализа безопасности сетевых устройств Positive Technologies и Вере Красковой, которая отдыхала Крыму во время наших исследований и выступила в роли пеленгуемого абонента 🙂
Изменение формата DIDа и CIDа
Часто бывает, что оператор присылает номер звонящего в неудобном формате, а так же не корректно указывает номер DID. Рассмотрим как поправить эту ситуацию.
Для начала разберемся с понятиями:
DID (Direct Inward Dialing) — возможность АТС использовать несколько городских номеров для маршрутизации входящих вызовов. Попросту говоря, это ваш внешний номер, на который вам звонят клиенты
CID (Caller ID) — номер вызывающего абонента.
И так, провайдер присылает CID в формате +7XXXXXXXXX или 7XXXXXXXXXX а мы хотим 8XXXXXXXXXX (Причин тому может быть много: например возможность перезвонить абоненту нажатием одной кнопки на телефоне, или специфика используемой crm системы и т.д.)
Для решения данной проблемы нам нужно взять последние десять символов из CIDа и добавить к ним 8. Делается это путем создания своего контекста, в котором мы первично изменяем необходимые нам данные а потом дальше направляем во from-trunk. Соответственно в настройках нужного транка контекст нужно указать наш собственный (context=from-operator)
[from-operator]
exten => _.,1,Set(CALLERID(all)=8$
exten => _.,2,Set(CALLERID(ANI-all)=$
exten => _.,3,Goto(from-trunk,$
Второй случай бывает гораздо реже, это когда оператор присылает DID в каком-нибудь коротком виде типа 687 который никак не связан с номером компании. На скриншоте ниже видно как астериск принимает от оператора DID с номером 687
Так же мы видим что астериск не получает CID звонящего, вернее получает (если просмотреть SIP дебаги то оператор присылает номер звонящего в графе CALLERID(name)), а это уже третий случай который встречается очень редко.
Для решения первой проблемы нам необходимо так же создать свой контекст в котором принудительно направить вызов на экстеншн (номер) которой будет равен вашему DID (внешнему номеру)
Для решения проблемы с CID нам нужно CallerID звонящего брать из CALLERID(name)
[from-operator]
exten => _.,1,Set(CALLERID(all)=8$
exten => _.,2,Set(CALLERID(ANI-all)=$
exten => _.,3,Goto(from-trunk,4952326666) ; направляем вызов дальше в обработку во from-trunk на экстеншн равный нужному номеру вашего DID
Если все правильно то видим и CallerID звонящего и нужный DID
Только не забываем настроить входящую маршрутизацию, как это сделать можно посмотреть тут
Обработка Caller ID и отличительный звонок в 3CX Phone System
К нам часто обращаются с просьбой разъяснить принцип обработки входящего и исходящего Caller ID в 3CX Phone System. В этой статье мы постараемся ответить на этот вопрос. Кроме того, мы опишем принцип работы функции, называемой Dictinctive Ring (отличительный звонок). Она нечастно используется в современных организациях, потому что ей на смену пришли возможности CRM интеграции. Однако, для быстрого понимания, откуда пришел вызов, отличительный звонок может быть полезен.
Внимание! В 3CX Phone System v14 SP3 вы можете отключить обработку Caller ID по формату E164 (см. скриншот ниже).
Обработка Caller ID входящего вызова
Для обработки входящего Caller ID 3CX использует параметры, указанные в разделе интерфейса Параметры — АТС – e164.
3CX пытается определить тип вызова (номера), используя параметры, указанные в разделе Параметры — АТС – e164 (см. рис). Система проверяет входящий Caller ID слева направо.
Если система видит, что Caller ID принадлежит стране, в которой установлена система, то снова проверяется тип вызова: национальный (National) или городской (Local). При этом, если установлена опция Удалять, если в той же стране, проверяется только часть номера, не содержащая код страны.
Если Caller ID поступает в национальном формате, т.е. код региона не соответствует региону, в котором работает система (указанному в разделе Параметры — АТС – e164), никакая обработка номера не производится и он поступает на внутренний номер. Функция Distinctive Ringing добавляет в вызову дополнительный заголовок Alert-info: national. Номер поступает с отрезанной международной частью, поскольку была установлена опция Удалять, если в той же стране. IP телефон пользователя подаст сигнал в соответствии с настройками для национальных вызовов.
Если Caller ID начинается с кода региона, указанном в Параметры — АТС – e164, то он распознается как городской. Если установлена опция Удалять, если в том же регионе, Caller ID (с отрезанной интернациональной и национальной частью) поступает на добавочный номер 3CX. Функция Distinctive Ringing добавляет в вызову дополнительный заголовок Alert-info: local. IP телефон пользователя подаст сигнал в соответствии с настройками для городских вызовов.
Обработка Caller ID исходящего вызова
3CX Phone System обрабатывает исходящий номер по Исходящим правилам, используя цифры набранного номера. В соответствии с совпавшим Исходящим правилом выбирается нужный маршрут (SIP линия или шлюз).
Как определяется значение переменной OriginatorCallerID?
Изначально значение OriginatorCallerID не определено. Затем значение OriginatorCallerID задается параметром Исходящий Caller ID в настройках транка.
Затем, если добавочному номеру 3CX присвоен Внешний Caller ID, он присваивается переменной OriginatorCallerID.
Форматирование входящего и исходящего Caller ID
Начиная с 3CX Phone System v.12 SP1 номер звонящего абонента (Caller ID) с порта, транка, VoIP шлюза или VoIP провайдера можно получить в том виде, в котором он требуется администратору системы. Также можно модифицировать и исходящий номер, т.е. передавать его на порт / транк / шлюз / провайдеру в требуемом виде.
Примеры
1. Компании требуется, чтобы все международные американские номера были переформатированы в локальный формат. В этом случае достаточно простого правила
Source CID Pattern +(1)(…)(.*)
New Source CID Pattern 3
+ удаляется (игнорируется)
(1) соответсует коду страны США и передается в первой переменной 1
(…) соответстует трехзначному коду города и передается во второй переменной 2
(.*) соответсвует оставшимся цифрам номера и передается в третьей переменной 3
В нашем примере в новом переформатированном номере мы оставляем только третью переменную 3, что соответствует локальному номеру.
Было +12021234567, стало 1234567.
2. Компании требуется привести номер к национальному формату и добавить 0 в начале номера для быстрого обратного звонка клиенту. Входящий Caller ID имеет такой вид +17864722245.
Source CID Pattern +(1)(…)(.*)
New Source CID Pattern 023
В начало номера добавляется 0.
Переменные 2 (786) и 3 (4722245) сохраняются, приводя номер к национальному формату.
Было +17864722245, стало 07864722245.
Как определить местоположение по сетям сотовой связи (Cell ID)
Карта Участники OpenStreetMap
Существует множество способов определения местоположения, такие как спутниковая навигация (GPS), местоположение по беспроводным сетям WiFi и по сетям сотовой связи.
В данном посте мы попытались проверить, насколько хорошо работает технология определения местоположения по вышкам сотовой связи в городе Минске (при условии использования только открытых баз данных координат передатчиков GSM).
Принцип действия заключается в том, что сотовый телефон (или модуль сотовой связи) знает, каким приемопередатчиком базовой станции он обслуживается и имея базу данных координат передатчиков базовой станции можно приблизительно определить своё местоположение.
Как указано на странице Cell ID, открытых баз данных с координатами передатчиков сотовой связи не так уж и много. Например, это OpenCellID.org, содержащая 2 611 805 передатчиков (13042 из них в Беларуси) и openbmap.org, содержащая 695 294 передатчиков.
Ниже приведен скриншот с обозначенными передатчиками в западной части Минска. Как видно число базовых станций не равно нулю, что вселяет оптимизм и возможный положительный исход эксперимента.
Карта Участники OpenStreetMap
Теперь немного о том, что такое передатчик в понимании OpenCellID и каким образом наполняется база данных OpenCellID. Эта БД наполняется различными способами, наиболее простой — это установка на смартфон приложения, которое записывает координаты телефона и обслуживающую базовую станцию, а затем отсылает на сервер все измерения. На сервере OpenCellID происходит вычисление приблизительного местоположения базовой станции на основании большого числа измерений (см. рисунок ниже). Таким образом, координаты беспроводной сети вычисляются автоматически и являются очень приблизительными.
Карта Участники OpenStreetMap
Теперь перейдем к вопросу о том, как использовать эту базу данных. Есть два варианта: использовать сервис перевода Cell ID в координаты, который предоставляется сайтом OpenCellID.org, либо выполнять локальный поиск. В нашем случае локальный способ предпочтительней, т.к. мы собираемся проехать по 13-километровому маршруту, и работа через веб будет медленной и неэффективной. Соответственно нам необходимо скачать базу данных на ноутбук. Это можно сделать, скачав файл cell_towers.csv.gz c сайта downloads.opencellid.org.
База данных представляет собой таблицу в CSV-формате, описанном ниже:
Все сотовые модули поддерживают следующие команды: AT+CREG, AT+COPS (обслуживающая базовая станция), AT+CSQ (уровень сигнала от базовой станции). Некоторые модули позволяют узнать кроме обслуживающего передатчика также и соседние, т.е. выполнять мониторинг базовых станций с помощью команд AT^SMONC для Siemens и AT+CCINFO для Simcom. У меня в распоряжении был модуль SIMCom SIM5215Е.
Соответственно мы воспользовались командой AT+CCINFO, ее формат приведен ниже.
Мониторинг работает – можно ехать.
Маршрут пролег в западной части Минска по ул. Матусевича, пр. Пушкина, ул. Пономаренко, ул. Шаранговича, ул. Максима Горецкого, ул. Лобанка, ул. Кунцевщина, ул. Матусевича.
Карта Участники OpenStreetMap
Запись лога велась с интервалом в 1 секунду. Выполняя преобразование CellID в координаты, выяснилось что 6498 обращений к базе данных OpenCellID были результативными, а 3351 обращений не нашли соответствий в БД. Т.е. hit rate для Минска составляет примерно 66 %.
На рисунке ниже показаны все передатчики, которые встречались в логе и были в БД.
Карта Участники OpenStreetMap
На рисунке ниже показаны все обслуживающие передатчики, которые встречались в логе и были в базе данных. Т.е. подобный результат можно получить на любом сотовом модуле или телефоне.
Карта Участники OpenStreetMap
Как видим, в один из моментов нас обслуживал передатчик, находящийся за транспортной развязкой на пересечении ул. Притыцкого и МКАД. Скорее всего, это загородная базовая станция, обслуживающая абонентов на расстоянии в несколько километров, что ведет к значительным ошибкам в определении местоположения по Cell ID.
Поскольку наш SIMCom SIM5215Е в каждый момент времени показывает не только обслуживающий передатчик, но также соседние и уровни сигнала от них, то попробуем рассчитать координаты аппарата на основании всех данных, имеющихся в конкретный момент времени.
Расчет координат абонента будем выполнять как взвешенное среднее координат передатчиков:
Latitude = Sum (w[n] * Latitude[n] ) / Sum(w[n])
Longitude = Sum (w[n] * Longitude[n]) / Sum(w[n])
Как известно из теории распространения радиоволн, затухание радиосигнала в вакууме пропорционально квадрату расстояния от передатчика до приемника. Т.е. при удалении в 10 раз (например, с 1 км до 10 км) сигнал станет в 100 раз слабее, т.е. уменьшится на 20 дБ по мощности. Соответственно вес при каждом слагаемом определяется как:
w[n] = 10^(RSSI_in_dBm[n] / 20)
Здесь мы допустили, что мощность всех передатчиков одинаковая, это допущение ошибочно. Но ввиду отсутствия информации о мощности передатчика базовой станции приходится идти на заведомо грубые допущения.
В результате получаем более подробную картину местоположений.
Карта Участники OpenStreetMap
По итогу маршрут оказался неплохо прочерчен за исключением выброса в сторону развязки на МКАД, по ранее описанной причине. Кроме того, со временем база данных координат будет наполнятся, что также должно повысить точность и доступность технологии определения местоположения по Cell ID.
Спасибо за внимание. Вопросы и комментарии приветствуются.