возможно здесь допустил неточность, так как тестировал на себе небольшое время. тут есть еще несколько нюансов, про которые не написал. после более тщательных исследований и выборки побольше откорректирую.
меня тоже занимает этот вопрос. у меня есть предположение, что это связано с тем, что встроенные адаптеры Wi-Fi не очень подходят для этих целей, а именно частота дискретизации не позволяет сделать с необходимой точностью преобразование Фурье (на чем, как мне кажется, основаны все эти алгоритмы).
У меня сформировался ответ по поводу того, стоит ли использовать технологию Wi-Fi позиционирования. Ответ — стоит. Почему? Если говорить о подсистеме wIPS, то нам в первую очередь нужно найти устройство (вражеское, своё, точку, клиента). И для этой задачи имеющихся характеристик достаточно.
Для Wi-Fi аналитики вопрос открытый, для каких-то задач достаточно, для каких-то нужно добавлять модули мониторинга для получения позиционирования в реальном времени.
Добрый день! Я помню ваш комментарий и обсуждение по поводу Probe Request, я даже хотел написать в обсуждение, что вот написал статью, но вы меня опередили. По поводу iOS 9 честно не тестировал. Судя по описанию, могу предположить, что, если он будет подключен к сети, то вести он себя будет аналогично Android. Если же устройство не подключено (not associated) то по всей видимости отследить историю перемещения устройства просто так мы не сможем. Сейчас я уже закончил испытания и у меня кончилась временная лицензия :(, но я постараюсь не забыть это потестировать, когда в следующий раз займусь стендом.
Давайте попробуем разобраться.
1. Чтобы упростить ситуацию, предлагаю начать с того, что решение о роуминге принимает Клиент. То, насколько быстро это произойдет, зависит от инфраструктуры, но это нас в данной задаче не волнует. Клиент понятия не имеет, что такое CAPWAP, поэтому то, как он работает, для клиента не имеет никакого значения.
Протокол CAPWAP определяет взаимодействие контроллера и точки, забирая на себя некоторые функции DSS (distribution system services), к механизму роуминга сам по себе этот протокол отношения не имеет.
То, что на probe request точка доступа должна отдать probe response — это верно, но это верно для любой архитектуры, контроллерной, автономной. И это тоже в общем к самому процессу роуминга отношения не имеет.
Изначально в стандарте определяются следующие требования к роумингу:
1. Клиент должен послать Reassociation request той точке, куда хочет подключиться
2. Точка должна ответить Reassociation response ( разрешить подключиться или нет).
То, каким образом Клиент выбирает точку, к которой хочет подключиться не определено в стандарте. И это ключевой момент!
Каждый производитель сам решает, как это делать. Так сложилось, что перед самим моментом роуминга клиенты часто посылают probe request на все каналы и слушают ответы, чтобы видимо окончательно обновить таблицу характеристик точек доступа, куда можно сделать роуминг и уже окончательно решить, куда слать Reassociation request. Мне этот подход кажется достаточно топорным. В самом начале становления этой технологии это еще проходило, но сейчас видно, что производители сами пытаются этот механизм оптимизировать.
2. Механизм ClientLink основан на том, что сигналы, передающиеся с разных антенн физически разнесены, у них разные физические пути. Мы не имеем понятия о траектории путей (тут могут быть отражения, преломления, затухание сигнала и многое другое, что конечно влияет так же и на фазу), вариантов таких траекторий очень много. Если бы мы знали траекторию, то, возможно, мы могли бы как-то предположить расстояние до Клиента, но так как мы траекторию не знаем, то и только на основе фаз рассчитать траекторию и расстояние не удастся.
3. Я бы хотел тут отметить несколько моментов
а) позиционирование — это не сервис, это инструмент, можно сказать, что это транспорт для сервисов. Сервис определяет требования к транспорту. Я уже перечислил несколько сервисов, которым достаточно транспорта Wi-Fi позиционирования.
б) я вообще говорю о Wi-Fi позиционировании «дешево и сердито», когда вы, устанавливая одну виртуальную машину ( стоимость этой машины ну 5% от стоимости инфраструктуры, может меньше), получаете достаточно мощный инструмент, который может использоваться для систем wIPS, для беспроводной аналитики, других задач. За 5% вы получаете представление о местонахождении и передвижении беспроводных пользователей, да, не с точностью до метра и не в реальном времени, но все равно, этой информации много для чего хватает.
в) нужно понимать разницу между определением местоположения персональных wi-fi клиентов и специализированных wi-fi устройств. как я писал, решения о позиционировании активных wi-fi меток очень неплохо себя зарекомендовало. Они посылают только строго probe request и строго один раз в определенный промежуток времени. Работают до месяца автономно. Это очень неплохо. Если промежутки времени уменьшить до секунд, мы получим позиционирование в реальном времени.
1. В этом то и весь смысл, что на все каналы, без этого бы позиционирование не работало.
Да и по поводу того, что именно _должен_ идти probe request я бы тоже поспорил. Что мешает слушать beacon пакеты ( в которых содержится точно такая же информация), которые идут с периодичностью 102.4мс независимо ни от чего от точки? Понятно, что сравнительно редко, но их можно услышать задолго до момента роуминга.
2. Beamforming даёт представление _только_ о смещениях фаз сигнала на разных антеннах. На самом деле больше ничего ему и не надо. Он понятия не имеет о геопозиции сигнала.
Я ничего не нашел в описанииTxBF, который входит в стандарт 802.11n, применительно к позиционированию.
3. Я хочу сказать, что не бывает плохой технологии. Для каждой технологии есть подходящая задача, нужно просто найти правильную технологию и правильно определить задачу :) Вы правильно заметили про орехи и микроскоп. Тут как раз идея стоит в том, чтобы найти правильную задачу для микроскопа (или молотка).
Данной точности позиционирования Wi-Fi вполне достаточно для общего отслеживания местоположения и перемещения клиентов, но не очень достаточно для отслеживания перемещения клиентов в реальном времени, это да.
1. То, что при роуминге посылается на все каналы Probe Request, я бы не сказал, что лежит на поверхности. Я не так много видел материалов, где про это упоминается. Ни в экзаменах Cisco, ни в CWNP треках я этого не видел. Это не так уж и очевидно. Намного очевидней, что используется протокол 802.11k, который входит в IEEE 802.11-2012 для роуминга.
2. ClientLink основывается на передаче одного сигнала в разных фазах с разных антенн с целью совмещения фаз на приёмнике и с моей точки зрения эта технология никак не связана с технологией позиционирования, которая основывается на RSSI триангуляции — получение замеров мощности сигнала клиента с трех точек, чья геопозиция заранее известна ( см. первую статью).
3. Есть много задач, которые может решать позиционирование и много технологий позиционирования с разной точностью. Наиболее наглядно это можно посмотреть, к примеру здесь на графике 6.
Моя задача была показать, на что способно именно Wi-Fi позиционирование без применения доп. оборудования.
Bluetooth Low Energy (BLE) решает вполне определенные, по моему мнению довольно узкие задачи (и решает достаточно хорошо), его я тоже планирую коснуться в своих статьях.
мои расчеты, действительно, вписались в заявленные параметры производителя. Но статья не об этом, она немного глубже, в частности она отвечает, почему параметры именно такие и как этим можно попробовать поуправлять. в частности в этом data sheet нет ничего о принципах работы роуминга и как он влияет на частоту замеров и, следовательно точность и достоверность результатов, что я считаю ключевым моментом для понимания данной темы. Я вижу здесь весьма общую фразу «Devices can send probe packets very infrequently. Up to 90 seconds (client dependent)», что совершенно недостаточно для понимания сути процесса.
В целом да, согласен, но тут еще играет роль, что Probe Request в принципе достаточно специфичный пакет и я бы на него, по хорошему, не рассчитывал.
Если Клиент находится на одном месте с устойчивым сигналом, он не должен генерить такой пакет вообще: он генерится один раз при подключении, либо во время роуминга (и то, по хорошему от этого тоже надо отказываться).
А метка может достаточно «компактно» генерить с необходимой периодичностью трафик и работать долго.
Я думаю это зависит в том числе и от количество «вбитых» профилей и настроек профилей типа «подключаться даже если сеть не ведет вещание».
В моём случае (CMX так делает) замер происходил по пакетам Probe Request ( насколько я понял).
Я полагаю, что по умолчанию телефон периодически рассылает Probe Request по всем вбитым профилям, работая в режиме «подключаться даже если сеть не ведет вещание». Именно замеры этих пакетов и используются. Замеры этих пакетов удобны потому, что они посылаются клиентом последовательно на все каналы (то есть все точки доступа могут их услышать) и посылаются всегда на максимальной мощности.
Скорее всего iphone не так часто шлет Probe Request по какой-то причине: либо из за алгоритма работы, либо просто из-за того, что там меньше вбитых профилей или они по другому настроены ( к примеру подключаются только если пассивно видят биконы точек ( пассивное сканирование), а не используют активное сканирование).
Такие технологии, как Cisco FastLocation используют замеры в том числе и Data пакетов за счет использования дополнительного модуля мониторинга.
В целом это очень интересный вопрос и я хочу его подробно рассмотреть в следующей статье.
Большое спасибо за вопрос. Я ведь для статьи копал в эту сторону и у меня даже есть что сказать, но, пока писал, этот момент я упустил. Я этот момент распишу тогда в следующей статье, тем более к следующей статье это так же имеет отношение.
Cisco в своей прошлой версии позиционирования (до версии 8.0) использовало две технологии: триангуляцию и Fingerprint. Благодаря этому в частности до восьмой версии включительно был так же доступен механизм калибровки.
В новой версии ( CMX 10) механизм калибровки отсутствует, я спрашивал у консультанта Cisco, ответ был такой, что это потому что технология Fingerprint теперь не используется. К сожалению, документация по 10-й версии пока не такая подробная. Поэтому я пока делаю вывод, что в 10-й версии используется только триангуляция.
Почему отказались от Fingerprint открыто не объясняется. Я подозреваю, либо потому что не сделали ( так как 10-я версия — это полностью новый продукт), либо потому что проявились какие-то тяжелорешаемые проблемы. Мне было бы самому интересно узнать ответ на этот вопрос.
Для Wi-Fi аналитики вопрос открытый, для каких-то задач достаточно, для каких-то нужно добавлять модули мониторинга для получения позиционирования в реальном времени.
1. Чтобы упростить ситуацию, предлагаю начать с того, что решение о роуминге принимает Клиент. То, насколько быстро это произойдет, зависит от инфраструктуры, но это нас в данной задаче не волнует. Клиент понятия не имеет, что такое CAPWAP, поэтому то, как он работает, для клиента не имеет никакого значения.
Протокол CAPWAP определяет взаимодействие контроллера и точки, забирая на себя некоторые функции DSS (distribution system services), к механизму роуминга сам по себе этот протокол отношения не имеет.
То, что на probe request точка доступа должна отдать probe response — это верно, но это верно для любой архитектуры, контроллерной, автономной. И это тоже в общем к самому процессу роуминга отношения не имеет.
Изначально в стандарте определяются следующие требования к роумингу:
1. Клиент должен послать Reassociation request той точке, куда хочет подключиться
2. Точка должна ответить Reassociation response ( разрешить подключиться или нет).
То, каким образом Клиент выбирает точку, к которой хочет подключиться не определено в стандарте. И это ключевой момент!
Каждый производитель сам решает, как это делать. Так сложилось, что перед самим моментом роуминга клиенты часто посылают probe request на все каналы и слушают ответы, чтобы видимо окончательно обновить таблицу характеристик точек доступа, куда можно сделать роуминг и уже окончательно решить, куда слать Reassociation request. Мне этот подход кажется достаточно топорным. В самом начале становления этой технологии это еще проходило, но сейчас видно, что производители сами пытаются этот механизм оптимизировать.
2. Механизм ClientLink основан на том, что сигналы, передающиеся с разных антенн физически разнесены, у них разные физические пути. Мы не имеем понятия о траектории путей (тут могут быть отражения, преломления, затухание сигнала и многое другое, что конечно влияет так же и на фазу), вариантов таких траекторий очень много. Если бы мы знали траекторию, то, возможно, мы могли бы как-то предположить расстояние до Клиента, но так как мы траекторию не знаем, то и только на основе фаз рассчитать траекторию и расстояние не удастся.
3. Я бы хотел тут отметить несколько моментов
а) позиционирование — это не сервис, это инструмент, можно сказать, что это транспорт для сервисов. Сервис определяет требования к транспорту. Я уже перечислил несколько сервисов, которым достаточно транспорта Wi-Fi позиционирования.
б) я вообще говорю о Wi-Fi позиционировании «дешево и сердито», когда вы, устанавливая одну виртуальную машину ( стоимость этой машины ну 5% от стоимости инфраструктуры, может меньше), получаете достаточно мощный инструмент, который может использоваться для систем wIPS, для беспроводной аналитики, других задач. За 5% вы получаете представление о местонахождении и передвижении беспроводных пользователей, да, не с точностью до метра и не в реальном времени, но все равно, этой информации много для чего хватает.
в) нужно понимать разницу между определением местоположения персональных wi-fi клиентов и специализированных wi-fi устройств. как я писал, решения о позиционировании активных wi-fi меток очень неплохо себя зарекомендовало. Они посылают только строго probe request и строго один раз в определенный промежуток времени. Работают до месяца автономно. Это очень неплохо. Если промежутки времени уменьшить до секунд, мы получим позиционирование в реальном времени.
Да и по поводу того, что именно _должен_ идти probe request я бы тоже поспорил. Что мешает слушать beacon пакеты ( в которых содержится точно такая же информация), которые идут с периодичностью 102.4мс независимо ни от чего от точки? Понятно, что сравнительно редко, но их можно услышать задолго до момента роуминга.
2. Beamforming даёт представление _только_ о смещениях фаз сигнала на разных антеннах. На самом деле больше ничего ему и не надо. Он понятия не имеет о геопозиции сигнала.
Я ничего не нашел в описанииTxBF, который входит в стандарт 802.11n, применительно к позиционированию.
3. Я хочу сказать, что не бывает плохой технологии. Для каждой технологии есть подходящая задача, нужно просто найти правильную технологию и правильно определить задачу :) Вы правильно заметили про орехи и микроскоп. Тут как раз идея стоит в том, чтобы найти правильную задачу для микроскопа (или молотка).
Данной точности позиционирования Wi-Fi вполне достаточно для общего отслеживания местоположения и перемещения клиентов, но не очень достаточно для отслеживания перемещения клиентов в реальном времени, это да.
2. ClientLink основывается на передаче одного сигнала в разных фазах с разных антенн с целью совмещения фаз на приёмнике и с моей точки зрения эта технология никак не связана с технологией позиционирования, которая основывается на RSSI триангуляции — получение замеров мощности сигнала клиента с трех точек, чья геопозиция заранее известна ( см. первую статью).
3. Есть много задач, которые может решать позиционирование и много технологий позиционирования с разной точностью. Наиболее наглядно это можно посмотреть, к примеру здесь на графике 6.
Моя задача была показать, на что способно именно Wi-Fi позиционирование без применения доп. оборудования.
Bluetooth Low Energy (BLE) решает вполне определенные, по моему мнению довольно узкие задачи (и решает достаточно хорошо), его я тоже планирую коснуться в своих статьях.
Если Клиент находится на одном месте с устойчивым сигналом, он не должен генерить такой пакет вообще: он генерится один раз при подключении, либо во время роуминга (и то, по хорошему от этого тоже надо отказываться).
А метка может достаточно «компактно» генерить с необходимой периодичностью трафик и работать долго.
В моём случае (CMX так делает) замер происходил по пакетам Probe Request ( насколько я понял).
Я полагаю, что по умолчанию телефон периодически рассылает Probe Request по всем вбитым профилям, работая в режиме «подключаться даже если сеть не ведет вещание». Именно замеры этих пакетов и используются. Замеры этих пакетов удобны потому, что они посылаются клиентом последовательно на все каналы (то есть все точки доступа могут их услышать) и посылаются всегда на максимальной мощности.
Скорее всего iphone не так часто шлет Probe Request по какой-то причине: либо из за алгоритма работы, либо просто из-за того, что там меньше вбитых профилей или они по другому настроены ( к примеру подключаются только если пассивно видят биконы точек ( пассивное сканирование), а не используют активное сканирование).
Такие технологии, как Cisco FastLocation используют замеры в том числе и Data пакетов за счет использования дополнительного модуля мониторинга.
В целом это очень интересный вопрос и я хочу его подробно рассмотреть в следующей статье.
В целом это интересный вопрос
Cisco в своей прошлой версии позиционирования (до версии 8.0) использовало две технологии: триангуляцию и Fingerprint. Благодаря этому в частности до восьмой версии включительно был так же доступен механизм калибровки.
В новой версии ( CMX 10) механизм калибровки отсутствует, я спрашивал у консультанта Cisco, ответ был такой, что это потому что технология Fingerprint теперь не используется. К сожалению, документация по 10-й версии пока не такая подробная. Поэтому я пока делаю вывод, что в 10-й версии используется только триангуляция.
Почему отказались от Fingerprint открыто не объясняется. Я подозреваю, либо потому что не сделали ( так как 10-я версия — это полностью новый продукт), либо потому что проявились какие-то тяжелорешаемые проблемы. Мне было бы самому интересно узнать ответ на этот вопрос.