Это третья, пока заключительная статья из серии Wi-Fi позиционирования «дешево и сердито»: когда не используются специализированные клиентские устройства и специализированная инфраструктура, а используются только общедоступные персональные устройства (смартфоны, планшеты, ноутбуки) и обычная инфраструктура Wi-Fi.
В первых двух статьях я делал основной акцент на точности и достоверности позиционирования, не касаясь вопроса частоты замеров. Если Клиент находится в статическом положении, частота замеров не имеет критичного значения, а если Клиент движется, то частота замеров начинает играть существенную роль.
Отправной точкой при расчёте частоты замеров является такая характеристика как характерная скорость движения Клиентов. Для человека это 5км/ч или 1.5 м/с. Для обеспечения позиционирования в реальном времени промежуток времени между двумя замерами не должен превышать удвоенную точность позиционирования, что позволяет строить достаточно точные для практических целей траектории движения.
Точность классического позиционирования по тестам, проведенным в предыдущей статье, составляла порядка пяти метров с достоверностью 90%. В этом случае частота замеров должна быть не менее 6,6с (либо 13,3 секунды для точности 10 метров). Теперь осталось выяснить, какова реальная частота замеров и соответствует ли она заявленной точности позиционирования.
Для тестов используется смартфон на Android 4.4.4 и ноутбук с Windows 7.
Что ж, цель ясна, средства понятны, приступим!
В специализированных системах позиционирования частотой замеров можно управлять на уровне работы драйверов беспроводного адаптера и программного обеспечения, регулируя интервалы передачи информации, тем самым подстраиваясь под характерную скорость клиента и точность позиционирования.
С персональными Wi-Fi устройствами (смартфоны, планшеты, ноутбуки) дело обстоит иначе: мы можем работать только с тем, что определено в стандартах IEEE 802.11-2012, драйверами производителя, настройками операционной системы.
Точки доступа (ТД) используют для позиционирования уровень сигнала (RSSI) Wi-Fi клиента (Клиент). Назову наличие на ТД одного измеренного уровня сигнала Клиента Замером.
Для решения задачи позиционирования необходимо иметь как минимум по одному Замеру с трех точек доступа. Чтобы не было путаницы, буду называть такой набор Сэмплом.
Точки доступа, Замеры которых формируют Сэмпл в общем случае работают на трех разных каналах, допустим, первый, шестой и 11-й (это связано с работой стандартов IEEE 802.11).
В соответствии со стандартами IEEE 802.11, Wi-Fi адаптер может находиться в одном из трех состояниях:
— передача (Tx)
— приём (Rx)
— мониторинг (CCA — Clear Channel Assessment)
Если ТД не передаёт и не принимает, она находится в режиме мониторинга своего канала (в частности для оценки виртуальной (CCA-CS, Carrier Sense) и физической (CCA-ED, Energy Detect) занятости канала).
Если Клиент находится в зоне уверенного приёма одной точки доступа, то он передаёт и принимает на одном канале. Возвращаясь к тому, из чего формируется Сэмпл, возникает вопрос, каким образом сформируется Сэмпл, если Клиент работает только в одном канале, а Замеры должны быть на трех разных каналах?
Современные точки доступа небольшую часть времени тратят на мониторинг смежных каналов, но так как основной задачей точек доступа остаётся обслуживание клиентов, а мониторинг всех каналов происходит последовательно, то время нахождения на смежном канале очень мало. К примеру, в инфраструктуре Cisco точка доступа обходит все каналы за 16 секунд. В этом случае вероятность «поймать» Замер клиента на смежном канале невелика. Поэтому этот способ мы отметаем.
Для мониторинга смежных каналов производители часто применяют дополнительное радио. К таким технологиям относится Cisco FastLocation. Модуль мониторинга перебирает все возможные каналы, но находится на каждом канале заметно дольше. Но опять же, эта роскошь по условиям задачи нам не доступна. Более детально технологии Cisco FastLocation я собираюсь посвятить отдельную статью.
В беспроводной среде есть огромное количество процессов, которые протекают незаметно для пользователя. Есть три типа пакетов (Data, Control, Management) и как минимум 39 типов фреймов, и есть всего один фрейм (и один режим работы беспроводного клиента), который позволяет решить поставленную задачу.
Это режим активного сканирования (active scanning), когда Клиент активно (посылая пакеты Probe Request) сканирует все доступные каналы на предмет наличия подходящей беспроводной сети. Probe Request, как фрейм управления (management frame), посылается на максимальной мощности и на самой низкой скорости передачи. Именно этот режим позволяет точкам доступа, работающим на других каналах, получить Замер с Клиента и сформировать Сэмпл.
Есть как минимум два режима работы, когда используется сканирование:
1. При выборе клиентом подходящей точки доступа, для подключения к беспроводной сети
2. При выборе клиентом подходящей точки доступа во время перехода с точки на точку (во время роуминга)
Клиенту доступно два механизма сканирования радиосреды:
— пассивное сканирование (passive scanning)
— активное сканирование (active scanning)
В первом случае беспроводной клиент слушает beacon пакеты (посылаемые каждые 102,4мс. по умолчанию), во втором – посылает probe request и дожидается probe response.
Очевидно, что это вопрос выбора между скоростью сканирования и затрачиваемой на это энергией (самый затратный режим работы беспроводного клиента – это передача).
Допустим, мы производим сканирование в диапазоне 2.4ГГц в России, где разрешено 13-ть каналов. Приёмник беспроводного клиента должен находиться, очевидно, не менее 102.4мс (стандартный интервал между beacon пакетами) в режиме мониторинга на каждом канале. Полный цикл сканирования занимает в районе 1.4с.
Клиент посылает запрос в канал (Probe Request). Точки доступа, работающие на этом канале и услышавшие запрос, отвечают на него информацией о имеющихся беспроводных сегментах (SSID).
Запрос может быть направленный (содержащий определенный SSID) — directed probe request, в этом случае ТД должна ответить информацией только об этом SSID (если он на ней есть).
Запрос может быть всенаправленный (Null Probe Request), в этом случае ТД, услышавшая данный пакет, должна предоставить информацию о всех настроенных SSID.
Клиент посылает Probe Request на первом канале и запускает ProbeTimer. Величина ProbeTimer не стандартизована и в зависимости от реализации драйверов сетевого адаптера может отличаться, но в общем случае она составляет 10мс. В течении этого времени беспроводной клиент обрабатывает ответы (Probe Response от ТД). Далее переходит на следующий канал и так по всем каналам. После чего решает, к какой ТД подключиться.
Полный цикл сканирования в этом случае занимает порядка 130мс, что примерно на порядок меньше пассивного сканирования.
Каждый производитель самостоятельно выбирает тип сканирования и условия его применения. Так же в самой операционной системе может быть опции, позволяющие выбрать определенный режим.
С моей точки зрения после подключения к SSID и находясь в зоне уверенного приёма одной точки доступа, Клиент не должен посылать Probe Request вообще.
Производитель Cisco говорит, что интервал передачи может быть в пределах от 10 секунд до 5 минут, в зависимости от типа Клиента, ОС, драйверов, батареи, активности клиента (http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/CMX_FastLocate_DG/b_CMX-FastLocate-DG.html).
Получается, что теория несколько противоречит практике, поэтому тут необходимы тесты.
Сначала тестам подвергся ноутбук в статическом положении, подключенный к сети, режим максимального потребления. На одном профиле у меня были отметки «подключаться автоматически» и «подключаться, даже если сеть не ведет вещание своего имени (SSID).
Результат показал, что система примерно раз в минуту посылает на все каналы всенаправленный Probe request независимо ни от чего.
То есть система, находясь в статическом положении, в зоне уверенного приёма одной ТД, всё равно каждую минуту отправляет на все каналы Probe request (на каждый запрос все точки доступа посылают probe response, что формирует немалый траффик). В режиме Maximum Battery Life ноутбук показал тот же результат.
Так же видно, что каждый раз Клиент посылает не один запрос, а сразу несколько, с совсем небольшим временным промежутком.
Количество Probe Request и количество Сэмплов на Cisco CMX совпала. Причем по логам видно, что раз в минуту приходит несколько Замеров (как показывает и анализатор), но CMX, очевидно, объединяет такие запросы (и правильно делает), так как счетчик каждую минуту увеличивался на один. Выглядело это примерно так:
В движении периодичность изменилась и появилась связь с моментом роуминга. Как показал анализатор, действительно, перед моментом роуминга ноутбук слал Probe Request на все каналы, то есть выполнял процедуру активного сканирования.
Тут возникает интересный эффект: чем быстрее двигается человек, тем чаще происходит роуминг. Но, к сожалению, роуминг происходит несколько реже, чем каждые 10 метров (удвоенная точность). Клиент держится «до последнего» за точку доступа и только в последний момент переключается на новую. В результате роуминг происходил не менее, чем каждые 15-20 метров, что примерно в два раза больше требуемого, в результате мы имеем не очень достоверную траекторию движения (см. предыдущую статью).
Далее я проводил тесты со смартфоном на базе Android 4.4.4. У смартфона есть два режима работы: активный и спящий. В спящем режиме есть несколько вариантов работы. Для тестов я использовал самый шумный режим «Never».
Результаты оказались следующими.
Если смартфон лежал на месте, и я им не пользовался, задержки составляли порядка 500-600 секунд. Даже в период активного серфинга задержки составляли порядка 100 секунд. Более частое обновление получалось за счет просмотра беспроводных сетей (в этот момент посылались запросы.
В движении результаты получились аналогичны ноутбуку, то есть прослеживалась прямая связь между посылкой пакетов и роумингом.
1. В классическом Wi-Fi позиционировании замеры производятся по пакетам Probe Request
2. На персональных устройствах (ноутбуках, планшетах, смартфонах) частота посылки Probe Request зависит от большого количество факторов: типа устройства, ОС, типа драйверов и их настройки, состоянии батареи, активности клиента и может составлять от 5 секунд до 10 минут. Но!
3. Есть прямая связь между скоростью передвижения клиента (частотой роуминга) и частотой посылки Probe Request. Если клиент находится в статическом положении, то частота замеров небольшая (но она и не нужна большая!). А в случае движения начинают формироваться Probe Request по событию роуминга. Но!
4. Частота посылки Probe Request по событию роуминга недостаточна (больше, чем удвоенная точность позиционирования) и при равномерном движении может составлять 10-15 секунд (а требуется как минимум 5-10 секунд), что приводит к ухудшению точности позиционирования в движении не меньше чем в два раза.
Многие производители стараются оптимизировать работу своих устройств для увеличения времени работы устройства и первым претендентом на оптимизацию является режим «активного сканирования». Это приводит в том числе к тому, что такие устройства как iPhone и Android тоже, стали достаточно редко использовать этот режим работы, но в случае роуминга еще не отошли от использования Probe Request.
На помощь производителям, к сожалению, так же приходит протокол IEEE 802.11k, который вошел в новую версию стандарта 802.11-2012. Этот стандарт берет на себя как раз ту функцию, которую сейчас выполняет активное сканирование при роуминге.
Из-за активной работы производителей в сторону уменьшения энергопотребления и внедрения стандарта 802.11k вряд ли можно ожидать на этом направлении улучшений.
Остаётся вариант использования для замеров пакетов данных (Data frame). В этом случае мы логично приходим к рассмотрению технологии Cisco FastLocaton в следующей статье.
P.S. Ниже небольшое отступление про активные Wi-Fi метки, про которые, если удастся с ними поработать, будет отдельная статья.
В случае применения активных Wi-Fi меток мы можем настроить их работу, как нам необходимо. Программное обеспечение настраивается таким образом, что метка постоянно находится в спящем режиме, просыпается с определенной периодичностью для посылки Probe Request на все каналы, после чего засыпает. С помощью такого режима работы можно добиться необходимой частоты обновления и необходимой продолжительности автономной работы.
Вот пример активной метки, которая просыпается каждые 90 секунд для посылки Probe Request, работает от двух АА-батареек порядка 27 дней.
P.P.S. Небольшое добавление. Поддержка протокола 802.11k может как ухудшить, так и улучшить Wi-Fi позиционирование. Пока ничего более конкретно сказать не могу, так как тема не изучена, постараюсь освятить в дальнейшем.
В первых двух статьях я делал основной акцент на точности и достоверности позиционирования, не касаясь вопроса частоты замеров. Если Клиент находится в статическом положении, частота замеров не имеет критичного значения, а если Клиент движется, то частота замеров начинает играть существенную роль.
Отправной точкой при расчёте частоты замеров является такая характеристика как характерная скорость движения Клиентов. Для человека это 5км/ч или 1.5 м/с. Для обеспечения позиционирования в реальном времени промежуток времени между двумя замерами не должен превышать удвоенную точность позиционирования, что позволяет строить достаточно точные для практических целей траектории движения.
Точность классического позиционирования по тестам, проведенным в предыдущей статье, составляла порядка пяти метров с достоверностью 90%. В этом случае частота замеров должна быть не менее 6,6с (либо 13,3 секунды для точности 10 метров). Теперь осталось выяснить, какова реальная частота замеров и соответствует ли она заявленной точности позиционирования.
Для тестов используется смартфон на Android 4.4.4 и ноутбук с Windows 7.
Что ж, цель ясна, средства понятны, приступим!
В специализированных системах позиционирования частотой замеров можно управлять на уровне работы драйверов беспроводного адаптера и программного обеспечения, регулируя интервалы передачи информации, тем самым подстраиваясь под характерную скорость клиента и точность позиционирования.
С персональными Wi-Fi устройствами (смартфоны, планшеты, ноутбуки) дело обстоит иначе: мы можем работать только с тем, что определено в стандартах IEEE 802.11-2012, драйверами производителя, настройками операционной системы.
Частота замеров, а что это?
Точки доступа (ТД) используют для позиционирования уровень сигнала (RSSI) Wi-Fi клиента (Клиент). Назову наличие на ТД одного измеренного уровня сигнала Клиента Замером.
Для решения задачи позиционирования необходимо иметь как минимум по одному Замеру с трех точек доступа. Чтобы не было путаницы, буду называть такой набор Сэмплом.
А сложно ли получить Сэмпл?
Точки доступа, Замеры которых формируют Сэмпл в общем случае работают на трех разных каналах, допустим, первый, шестой и 11-й (это связано с работой стандартов IEEE 802.11).
В соответствии со стандартами IEEE 802.11, Wi-Fi адаптер может находиться в одном из трех состояниях:
— передача (Tx)
— приём (Rx)
— мониторинг (CCA — Clear Channel Assessment)
Если ТД не передаёт и не принимает, она находится в режиме мониторинга своего канала (в частности для оценки виртуальной (CCA-CS, Carrier Sense) и физической (CCA-ED, Energy Detect) занятости канала).
Если Клиент находится в зоне уверенного приёма одной точки доступа, то он передаёт и принимает на одном канале. Возвращаясь к тому, из чего формируется Сэмпл, возникает вопрос, каким образом сформируется Сэмпл, если Клиент работает только в одном канале, а Замеры должны быть на трех разных каналах?
Современные точки доступа небольшую часть времени тратят на мониторинг смежных каналов, но так как основной задачей точек доступа остаётся обслуживание клиентов, а мониторинг всех каналов происходит последовательно, то время нахождения на смежном канале очень мало. К примеру, в инфраструктуре Cisco точка доступа обходит все каналы за 16 секунд. В этом случае вероятность «поймать» Замер клиента на смежном канале невелика. Поэтому этот способ мы отметаем.
Для мониторинга смежных каналов производители часто применяют дополнительное радио. К таким технологиям относится Cisco FastLocation. Модуль мониторинга перебирает все возможные каналы, но находится на каждом канале заметно дольше. Но опять же, эта роскошь по условиям задачи нам не доступна. Более детально технологии Cisco FastLocation я собираюсь посвятить отдельную статью.
Откуда все-таки тогда берется Сэмпл?!
В беспроводной среде есть огромное количество процессов, которые протекают незаметно для пользователя. Есть три типа пакетов (Data, Control, Management) и как минимум 39 типов фреймов, и есть всего один фрейм (и один режим работы беспроводного клиента), который позволяет решить поставленную задачу.
Это режим активного сканирования (active scanning), когда Клиент активно (посылая пакеты Probe Request) сканирует все доступные каналы на предмет наличия подходящей беспроводной сети. Probe Request, как фрейм управления (management frame), посылается на максимальной мощности и на самой низкой скорости передачи. Именно этот режим позволяет точкам доступа, работающим на других каналах, получить Замер с Клиента и сформировать Сэмпл.
Зачем Клиент посылает эти запросы?
Есть как минимум два режима работы, когда используется сканирование:
1. При выборе клиентом подходящей точки доступа, для подключения к беспроводной сети
2. При выборе клиентом подходящей точки доступа во время перехода с точки на точку (во время роуминга)
Клиенту доступно два механизма сканирования радиосреды:
— пассивное сканирование (passive scanning)
— активное сканирование (active scanning)
В первом случае беспроводной клиент слушает beacon пакеты (посылаемые каждые 102,4мс. по умолчанию), во втором – посылает probe request и дожидается probe response.
Очевидно, что это вопрос выбора между скоростью сканирования и затрачиваемой на это энергией (самый затратный режим работы беспроводного клиента – это передача).
Пассивное сканирование
Допустим, мы производим сканирование в диапазоне 2.4ГГц в России, где разрешено 13-ть каналов. Приёмник беспроводного клиента должен находиться, очевидно, не менее 102.4мс (стандартный интервал между beacon пакетами) в режиме мониторинга на каждом канале. Полный цикл сканирования занимает в районе 1.4с.
Активное сканирование
Клиент посылает запрос в канал (Probe Request). Точки доступа, работающие на этом канале и услышавшие запрос, отвечают на него информацией о имеющихся беспроводных сегментах (SSID).
Запрос может быть направленный (содержащий определенный SSID) — directed probe request, в этом случае ТД должна ответить информацией только об этом SSID (если он на ней есть).
Запрос может быть всенаправленный (Null Probe Request), в этом случае ТД, услышавшая данный пакет, должна предоставить информацию о всех настроенных SSID.
Клиент посылает Probe Request на первом канале и запускает ProbeTimer. Величина ProbeTimer не стандартизована и в зависимости от реализации драйверов сетевого адаптера может отличаться, но в общем случае она составляет 10мс. В течении этого времени беспроводной клиент обрабатывает ответы (Probe Response от ТД). Далее переходит на следующий канал и так по всем каналам. После чего решает, к какой ТД подключиться.
Полный цикл сканирования в этом случае занимает порядка 130мс, что примерно на порядок меньше пассивного сканирования.
Каждый производитель самостоятельно выбирает тип сканирования и условия его применения. Так же в самой операционной системе может быть опции, позволяющие выбрать определенный режим.
Какую частоту сканирования по Probe Request можно ожидать?
С моей точки зрения после подключения к SSID и находясь в зоне уверенного приёма одной точки доступа, Клиент не должен посылать Probe Request вообще.
Производитель Cisco говорит, что интервал передачи может быть в пределах от 10 секунд до 5 минут, в зависимости от типа Клиента, ОС, драйверов, батареи, активности клиента (http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/CMX_FastLocate_DG/b_CMX-FastLocate-DG.html).
Получается, что теория несколько противоречит практике, поэтому тут необходимы тесты.
Измерение частоты посылки Probe Request
Сначала тестам подвергся ноутбук в статическом положении, подключенный к сети, режим максимального потребления. На одном профиле у меня были отметки «подключаться автоматически» и «подключаться, даже если сеть не ведет вещание своего имени (SSID).
Результат показал, что система примерно раз в минуту посылает на все каналы всенаправленный Probe request независимо ни от чего.
То есть система, находясь в статическом положении, в зоне уверенного приёма одной ТД, всё равно каждую минуту отправляет на все каналы Probe request (на каждый запрос все точки доступа посылают probe response, что формирует немалый траффик). В режиме Maximum Battery Life ноутбук показал тот же результат.
Так же видно, что каждый раз Клиент посылает не один запрос, а сразу несколько, с совсем небольшим временным промежутком.
Есть ли корреляция между частотой посылки Probe Request и частотой замеров Cisco CMX
Количество Probe Request и количество Сэмплов на Cisco CMX совпала. Причем по логам видно, что раз в минуту приходит несколько Замеров (как показывает и анализатор), но CMX, очевидно, объединяет такие запросы (и правильно делает), так как счетчик каждую минуту увеличивался на один. Выглядело это примерно так:
TIMESTAMP :Fri Aug 26 10:43:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:43:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:43:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:43:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:43:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:43:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:44:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:44:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:44:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:44:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:44:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:45:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:45:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:45:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:45:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:45:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:46:14 MSK 2016
TIMESTAMP :Fri Aug 26 10:46:14 MSK 2016
TIMESTAMP :Fri Aug 26 10:46:14 MSK 2016
TIMESTAMP :Fri Aug 26 10:46:14 MSK 2016
TIMESTAMP :Fri Aug 26 10:46:14 MSK 2016
TIMESTAMP :Fri Aug 26 10:47:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:47:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:47:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:47:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:47:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:48:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:48:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:48:12 MSK 2016
TIMESTAMP :Fri Aug 26 10:48:12 MSK 2016Частота замеров в движении
В движении периодичность изменилась и появилась связь с моментом роуминга. Как показал анализатор, действительно, перед моментом роуминга ноутбук слал Probe Request на все каналы, то есть выполнял процедуру активного сканирования.
Тут возникает интересный эффект: чем быстрее двигается человек, тем чаще происходит роуминг. Но, к сожалению, роуминг происходит несколько реже, чем каждые 10 метров (удвоенная точность). Клиент держится «до последнего» за точку доступа и только в последний момент переключается на новую. В результате роуминг происходил не менее, чем каждые 15-20 метров, что примерно в два раза больше требуемого, в результате мы имеем не очень достоверную траекторию движения (см. предыдущую статью).
Далее я проводил тесты со смартфоном на базе Android 4.4.4. У смартфона есть два режима работы: активный и спящий. В спящем режиме есть несколько вариантов работы. Для тестов я использовал самый шумный режим «Never».
Результаты оказались следующими.
Если смартфон лежал на месте, и я им не пользовался, задержки составляли порядка 500-600 секунд. Даже в период активного серфинга задержки составляли порядка 100 секунд. Более частое обновление получалось за счет просмотра беспроводных сетей (в этот момент посылались запросы.
В движении результаты получились аналогичны ноутбуку, то есть прослеживалась прямая связь между посылкой пакетов и роумингом.
Основные выводы
1. В классическом Wi-Fi позиционировании замеры производятся по пакетам Probe Request
2. На персональных устройствах (ноутбуках, планшетах, смартфонах) частота посылки Probe Request зависит от большого количество факторов: типа устройства, ОС, типа драйверов и их настройки, состоянии батареи, активности клиента и может составлять от 5 секунд до 10 минут. Но!
3. Есть прямая связь между скоростью передвижения клиента (частотой роуминга) и частотой посылки Probe Request. Если клиент находится в статическом положении, то частота замеров небольшая (но она и не нужна большая!). А в случае движения начинают формироваться Probe Request по событию роуминга. Но!
4. Частота посылки Probe Request по событию роуминга недостаточна (больше, чем удвоенная точность позиционирования) и при равномерном движении может составлять 10-15 секунд (а требуется как минимум 5-10 секунд), что приводит к ухудшению точности позиционирования в движении не меньше чем в два раза.
НА что следует обратить внимание
Многие производители стараются оптимизировать работу своих устройств для увеличения времени работы устройства и первым претендентом на оптимизацию является режим «активного сканирования». Это приводит в том числе к тому, что такие устройства как iPhone и Android тоже, стали достаточно редко использовать этот режим работы, но в случае роуминга еще не отошли от использования Probe Request.
На помощь производителям, к сожалению, так же приходит протокол IEEE 802.11k, который вошел в новую версию стандарта 802.11-2012. Этот стандарт берет на себя как раз ту функцию, которую сейчас выполняет активное сканирование при роуминге.
Из-за активной работы производителей в сторону уменьшения энергопотребления и внедрения стандарта 802.11k вряд ли можно ожидать на этом направлении улучшений.
Остаётся вариант использования для замеров пакетов данных (Data frame). В этом случае мы логично приходим к рассмотрению технологии Cisco FastLocaton в следующей статье.
P.S. Ниже небольшое отступление про активные Wi-Fi метки, про которые, если удастся с ними поработать, будет отдельная статья.
В случае применения активных Wi-Fi меток мы можем настроить их работу, как нам необходимо. Программное обеспечение настраивается таким образом, что метка постоянно находится в спящем режиме, просыпается с определенной периодичностью для посылки Probe Request на все каналы, после чего засыпает. С помощью такого режима работы можно добиться необходимой частоты обновления и необходимой продолжительности автономной работы.
Вот пример активной метки, которая просыпается каждые 90 секунд для посылки Probe Request, работает от двух АА-батареек порядка 27 дней.
P.P.S. Небольшое добавление. Поддержка протокола 802.11k может как ухудшить, так и улучшить Wi-Fi позиционирование. Пока ничего более конкретно сказать не могу, так как тема не изучена, постараюсь освятить в дальнейшем.
Поделиться с друзьями
Комментарии (13)
arcman
07.09.2016 17:28+1Спасибо за статью.
Если в классическом Wi-Fi позиционировании замеры производятся по пакетам Probe Request, то как оно поведет себя с iOS 9 устройствами (iPhone) для которых заявлено, что в Probe Request используется случайный MAC адрес?
Вот что пишет сама Apple:
«iOS uses a randomized Media Access Control (MAC) address when conducting Preferred Network Offload (PNO) scans when a device is not associated with a Wi-Fi network and its processor is asleep. A device’s processor goes to sleep shortly after the screen is turned off. PNO scans are run to determine if a user can connect to a preferred Wi-Fi network to conduct activity such as wirelessly syncing with iTunes.
iOS also uses a randomized MAC address when conducting enhanced Preferred Network Offload (ePNO) scans when a device is not associated with a Wi-Fi network or its processor is asleep. ePNO scans are run when a device uses Location Services for apps which use geofences, such as location-based reminders that determine whether the device is near a specific location.
Because a device’s MAC address now changes when it’s not connected to a Wi-Fi network, it can’t be used to persistently track a device by passive observers of Wi-Fi traffic, even when the device is connected to a cellular network.»
openalex
08.09.2016 10:57Добрый день! Я помню ваш комментарий и обсуждение по поводу Probe Request, я даже хотел написать в обсуждение, что вот написал статью, но вы меня опередили. По поводу iOS 9 честно не тестировал. Судя по описанию, могу предположить, что, если он будет подключен к сети, то вести он себя будет аналогично Android. Если же устройство не подключено (not associated) то по всей видимости отследить историю перемещения устройства просто так мы не сможем. Сейчас я уже закончил испытания и у меня кончилась временная лицензия :(, но я постараюсь не забыть это потестировать, когда в следующий раз займусь стендом.
arcman
08.09.2016 11:28+1Спасибо, будет интересно увидеть поведение iOS на практике.
Со своей стороны попробую послушать эфир снифером (у нас есть несколько iPhone у коллег в офисе), но у нас только одна точка доступа и как работает роуминг я не увижу.
Кстати Apple пишет что iOS уже поддерживает 802.11k, 802.11r и 802.11v:
https://support.apple.com/ru-ru/HT202628openalex
08.09.2016 11:32Будет интересно увидеть результат! Да, мне тоже интересно по поводу 802.11k, будет возможность, посмотрю в эту сторону тоже.
chaynick
http://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/connected-mobile-experiences/datasheet-c78-734648.html
)
openalex
мои расчеты, действительно, вписались в заявленные параметры производителя. Но статья не об этом, она немного глубже, в частности она отвечает, почему параметры именно такие и как этим можно попробовать поуправлять. в частности в этом data sheet нет ничего о принципах работы роуминга и как он влияет на частоту замеров и, следовательно точность и достоверность результатов, что я считаю ключевым моментом для понимания данной темы. Я вижу здесь весьма общую фразу «Devices can send probe packets very infrequently. Up to 90 seconds (client dependent)», что совершенно недостаточно для понимания сути процесса.
chaynick
Ну строго говоря в даташите и не должно быть технических подробностей, только маркетинговые (завышенные) цифры. Но в принципе влияние экономии батарей и роуминга на точность позиционирования лежит на поверхности. У cisco уже довольно давно есть технология clientlink, которая по сути и есть технология позиционирования, так что выкат технологий позиционирования wi-fi был лишь вопросом времени.
P.S. В Шереметьево используется система позиционирования клиентов на основе беспроводного протокола… Bluetooth. На редкость сумрачное решение, но как не странно на мой взгляд лучше приспособлено для отслеживания клиентов.
openalex
1. То, что при роуминге посылается на все каналы Probe Request, я бы не сказал, что лежит на поверхности. Я не так много видел материалов, где про это упоминается. Ни в экзаменах Cisco, ни в CWNP треках я этого не видел. Это не так уж и очевидно. Намного очевидней, что используется протокол 802.11k, который входит в IEEE 802.11-2012 для роуминга.
2. ClientLink основывается на передаче одного сигнала в разных фазах с разных антенн с целью совмещения фаз на приёмнике и с моей точки зрения эта технология никак не связана с технологией позиционирования, которая основывается на RSSI триангуляции — получение замеров мощности сигнала клиента с трех точек, чья геопозиция заранее известна ( см. первую статью).
3. Есть много задач, которые может решать позиционирование и много технологий позиционирования с разной точностью. Наиболее наглядно это можно посмотреть, к примеру здесь на графике 6.
Моя задача была показать, на что способно именно Wi-Fi позиционирование без применения доп. оборудования.
Bluetooth Low Energy (BLE) решает вполне определенные, по моему мнению довольно узкие задачи (и решает достаточно хорошо), его я тоже планирую коснуться в своих статьях.
chaynick
1. То что на все каналы — нет, но что при роуминге на точку доступа должен идти probe request вполне ожидаем.
2. Beamforming по сути дает нам вектор на клиента. Используя информацию такого рода с трех точек мы по сути получаем ту же триангуляцию. Другой вопрос что конкретно clientlink никто для геопозиционирования (насколько мне известно по крайней мере) не использует. Точно так же как на основе wi-fi c несколькими антеннами можно построить эрзац радар для отслеживания положения людей, это было не более чем обобщение, а не конкретное предложение по реализации.
3. Не спорю. Строго говоря я ни с чем в статье особо не спорю, скорее скептически отношусь к использованию хорошей технологии для задач, для которых она не предназначена. Ну право слово, как орехи микроскопом…
openalex
1. В этом то и весь смысл, что на все каналы, без этого бы позиционирование не работало.
Да и по поводу того, что именно _должен_ идти probe request я бы тоже поспорил. Что мешает слушать beacon пакеты ( в которых содержится точно такая же информация), которые идут с периодичностью 102.4мс независимо ни от чего от точки? Понятно, что сравнительно редко, но их можно услышать задолго до момента роуминга.
2. Beamforming даёт представление _только_ о смещениях фаз сигнала на разных антеннах. На самом деле больше ничего ему и не надо. Он понятия не имеет о геопозиции сигнала.
Я ничего не нашел в описанииTxBF, который входит в стандарт 802.11n, применительно к позиционированию.
3. Я хочу сказать, что не бывает плохой технологии. Для каждой технологии есть подходящая задача, нужно просто найти правильную технологию и правильно определить задачу :) Вы правильно заметили про орехи и микроскоп. Тут как раз идея стоит в том, чтобы найти правильную задачу для микроскопа (или молотка).
Данной точности позиционирования Wi-Fi вполне достаточно для общего отслеживания местоположения и перемещения клиентов, но не очень достаточно для отслеживания перемещения клиентов в реальном времени, это да.
chaynick
1. В принципе ничто, кроме CAPWAP) Насколько помню он должен обязательно отдать probe response в split mac mode.
2. Из дельты фаз и известной базы антенн можно получить направление.
3. Wi-fi шикарная технология, но использовать ее текущую реализацию для позиционирования не стоит. Скажем лучше выпустить драфт rfc 802.11XXX с новым фреймом, который отправляется по всем каналам каждые n мс иииии… получить умирающую за час батарею девайса. Это не плохо если можно определить позицию по wi-fi. Плохо что вообще возникло желание определять позицию по wi-fi, это говорит о том, что бизнес зашел в тупик — есть спрос на предложение, но нет его вменяемой реализации. А Cisco и Extreme networks (вроде у них тоже есть такая вещь, но могу и наврать) сейчас соревнуются в «мой микроскоп ухватистее на 10% и на 15% тяжелее конкурента!»
Но все вышенаписанное сугубо мое имхо, на лавры гуру я не претендую.
openalex
Давайте попробуем разобраться.
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 и строго один раз в определенный промежуток времени. Работают до месяца автономно. Это очень неплохо. Если промежутки времени уменьшить до секунд, мы получим позиционирование в реальном времени.
openalex
У меня сформировался ответ по поводу того, стоит ли использовать технологию Wi-Fi позиционирования. Ответ — стоит. Почему? Если говорить о подсистеме wIPS, то нам в первую очередь нужно найти устройство (вражеское, своё, точку, клиента). И для этой задачи имеющихся характеристик достаточно.
Для Wi-Fi аналитики вопрос открытый, для каких-то задач достаточно, для каких-то нужно добавлять модули мониторинга для получения позиционирования в реальном времени.