Probe request что это

Probe request что это

Телефон с включённым WiFi может периодически отправляет в эфир запросы, т.н. probe requests, содержащие MAC самого устройства и имя известной WiFi сети, с которой он соединялся ранее в надежде, что эта сеть ему ответит. Этот механизм, активный поиск, является альтернативным пассивному, когда устройство желая соеденится с сетью слушает эфир ожидая маячковые сообщения (beacon frames) от точки доступа [Passive WiFi Tracking].

Посмотреть пристальнее на эти пакеты можно в Wireshark используя фильтр wlan.fc.type_subtype == 4

Таким образом можно привязать конкретное устройство к wifi сети (с поправкой на то, что сетей с данным именем может быть несколько) и далее попытаться определить географическое положение этой сети. Последнее возможно при помощи геоинформационных сервисов в Интернете, например WiGLE (поиск по сетям доступен после регистрации). Если в Сети данных нет, то можно обойтись собственноручно собранной информацией о местоположении WiFi сетей, например с помощью мобильных приложений (Google Play: Wigle Wifi Wardriving).

Приём probe request

***
Наблюдать устройства посылающие probe requests можно и в airodump-ng. Утилита показывает активные устройства (мак, время появления, время последнего пакета, ESSID и т.д.). в реальном времени. Если включена запись в файл, то данные об эфире также будут сохранены в CSV файл.

Источник

My IT-blog

Слава Україні!

Wireless_Frames

Многие думают что проводные и беспроводные сети очень похожи, но это не так! давайте глубже посмотрим на работу беспроводных сетей.
План действий на сегодня(пункты не по порядку:)))), много картинок и непонятных слов
1. Типы беспроводных фреймов(кадров)
2. Структура 802.11 фрейма
3. Типы фреймов более детально
4. Как это все работает, в картинкааах:)
Кое где встречаются непонятные слова, далее по тексту они разжеваны:)

Беспроводная сеть, это half-duplex, или передаем или принимаем, работает на CSMA/CA, carrier sense означает что клиент должен определить чист ли эфир, не передает ли еще кто-то. Это достигается когда clear channel assessment (CCA) — мы слушаем. Но есть проблема hidden node — когда станции не слышат друг друга, находятся далеко друг от друга. Преодолевается с использованием virtual carrier sense (VCS). Среда передачи не будет доступной пока физическая и виртуальная несущая не скажут что они свободны:)

Каждая станция должна соблюдать interframe spacing (IFS) — время которая станция ждет перед отправкой, убивает сразу 2 зайцев, проверяет что среда чистая, и что фреймы не будут идти близко друг к другу и будут неверно распознаны.

Типы периодов IFS:
■ Short interframe space (SIFS): Высокий приоритет, используется для ACKs
■ Point-coordination interframe space (PIFS):Используется, когда AP будет контролировать сеть
■ Distributed-coordination interframe space (DIFS): Используется для фреймов данных, это нормальный промежуток между кадрами.

Прежде чем передать клиент должен слушать среду. Тут и начинается магия ваерлеса!
Включаем backoff timer — выбираем произвольное число и начинаем считать в обратном порядке. Скорость с какой происходит отсчет зависит от стандарта сети 802.11 а/b/g и называется slottime.

FHSS Slot Time = 50 microseconds
DSSS Slot Time = 20 microseconds
Infrared Slot Time = 8 microseconds.

PIFS = SIFS + 1 Slot Time
DIFS = PIFS + 1 Slot Time

Разберем это на примере

1. Станция А выбрала число 29
2. Станция А начала обратный отсчет 29 28 27 … Пока станция считает она слушает среду никто ли не передает.
3. Когда Станция А досчитала до 18, станция Б начала передачу длинной 45(это число хранится в хедере фрейма) и называется network allocation vector (NAV) который состоит из времени для отправки фрейма, ожидания SIFS, и получения АСК от точки доступа.
4. Станция A добавляет 45 к 18 и продолжает считать 63, 62, 61 итд. Общее время которое ожидает Станция А перед передачей — contention window.
5. Досчитав до 0, наша станция начинает передачу:)))

Если передача не удалась, Станция сбрасывает backoff timer, и начинает считать опять. Этот таймер растет с увеличением количества неудачных попыток передачи.
Перед первой передачей данный таймер может быть 0-31
после первой неудачи 0-127
с каждой следующей неудачей это число удваивается.

Если за координацию передачи данных ответственна станция(было рассмотрено в примере) то это называется distributed coordination function (DCF).
Если за координацию передачу данных ответственна точка доступа то это называется point coordination function (PCF).

Когда фрейм добрался нормально, отсылается АСК(использует SIFS). получили-подождали SIFS и отправили АСК с длительностью 0. что говорит о завершении передачи

Типы Wireless кадров(фреймов)
■ Management frames: используются для входа и выхода из сети. Включают: association request, association response и reassociation request и др
■ Control frames: подтверждение о получении фреймов данных
■ Data frames: фреймы содержащие данные

Wireless Header
Тема, во время глубокого анализа которой ваш мосх может выйти:)
То что можно снять ваершарком

а теперь фрейм в схематическом виде:

Frame Control содержит информацию для определения типа 802.11 фрейма и предоставляет информацию для его обработки.
Более подробно рассмотрим это поле:

Protocol Version текущая версия протокола 802.11. Клиенты используют это поле для определения поддерживается ли эта версия протокола.

Type и Subtype определяет функции фрейма(control, data, management). Также содержит несколько подтипов. Каждый подтип определяет специфическую функцию для данного типа фрейма.

To DS и From DS указывает фрейм идет в или вышел из DS (distributed system), и используется только в data фреймах клиентов связанных с определенной точкой доступа.

More Fragments указывает будут ли еще фреймы данных или management

Retry indicates указывает повторный или нет этот фрейм.

Power Management указывает является ли клиент в активном режиме или в режиме пониженного энергопотребления.

More Data указывает клиенту в режиме пониженного энергопотребления что у точки есть еще парочка кадров для отправки:) Также используется точками для указания, что будут дополнительные broadcast/multicast фреймы.

WEP указывает нужно ли использовать аутентификацию и шифрование для фрейма. Может быть установлен для всех data и management кадров, у которых установлен подтип задающий аутентификацию!

Order указывает что все полученные кадры данных должны обрабатываться по порядку.

Вернемся к нашему фрейму

Duration/ID Field
Используется для всех полей control, за исключением кадров с подтипом Power Save (PS) Poll, для указания времени, в нс, необходимого на передачу фрейма. Когда подтип PS Poll, то поле содержит association identity (AID) передающего клиента.

Address Fields
В зависимости от типа фрейма, 4 адреса будут содержать комбинацию таких типов адреса:

BSS Identifier (BSSID). BSSID уникальный идентификатор каждой BSS. Когда фрейм от клиента с infrastructure BSS, то BSSID это MAC адрес точки доступа. когда фрейм от клиента в режиме IBSS, тогда BSSID генерируется произвольно, локально администрируемый MAC адрес клиента который начал IBSS.

Destination Address (DA). DA указывает MAC получателя.

Source Address (SA). SA указывает MAC отправителя.

Receiver Address (RA). RA указывает MAC ближайшего клиента в беспроводной среде которому будет направлен фреймa.

Transmitter Address (TA). TA указывает MAC клиента который передаст фрейм в беспроводную среду.

Состоит из двух полей:

Sequence Number указывает порядковый номер каждого фрейма. Он одинаков для каждого фрагмента фрагментированного фрейма.(сорри за каламбур) Число увеличивается на единицу пока не достигнет 4095, а потом опять начинается с 0.

Fragment Number указывает количество отправленных фрагментов. Вначале =0, а потом увеличивается на 1 при отправке каждого фрагментика.

Frame Body содержимое полученное от верхних уровней модели оси:) например IP пакет:)

Frame Check Sequence передающий клиент использует cyclic redundancy check (CRC) для генерации FCS(контрольная сумма). Получатель также использует CRC для полученного фрейма и сравнивает с тем что шел в пакете. Так мы боремся с ошибками!

Типы фреймов и их подтипы:

Теперь о каждом типе фреймов отдельно:
Management — для управления соединением, всего 11 типов, рассмотрим самые распространенные
Beacons(подтип 8 ) и Probes
Когда клиент слышит Beacon он получает достаточно много информации о сети

Как мы видим содержит временную метку начала отсчета, интервал и поле называемое Capability Information — специфические параметры сети(режим энергосбережения, аутентификация и данный по преамбуле) Также содержит SSIDы которые поддерживает точка и скорости на которых она может работать и также 6 полей которые называются Parameter Set которые указывают тип модуляции итп Также есть Traffic Indication Map (TIM), которое указывает что у точке доступа есть буферизированный трафик для клиента в режиме энергосбережения.

Получив beacon фрейм клиент смотрит может ли он подключится к сети или нет, грубо говоря он позволяет клиенту пассивно сканировать сеть.

Активное сканирование сети с помощью probe request и probe response

По структуре probe response похож на beacon, отличие лишь в том что beacon отсылается с определенной периодичностью, а probe response только по запросу.
После того как клиент нашел точку получил параметры сети, он пытается конектится с помощью authentication фрейма.
Этот фрейм содержит информацию о алгоритме аутентификации, номере для аутентификации транзакции и о том была ли успешна аутентификация или нет.

Разорвать соединение может либо клиент либо точка, послав deauthentication сообщение, которое содержит в себе информацию кто покидает сеть. Клиент также может послать disassociation сообщение, с помощью которого он отсоединится от сети, но будет по прежнему аутентифицирован. Вернувшись клиент просто посылает reassociation сообщение, а точка отсылает reassociation ответ, таким образом отпадает необходимость в повторной аутентификации и пересоединении.

Control Frames
ACK — позволяет поддерживать соединение с уведомлением о получении фрейма. Также к Control фреймам относятся request to send (RTS) и clear to send (CTS).
ACK, RTS, и CTS используются в DCF режиме.
В режиме PCF используется:
Contention Free End (CF+End)
Contention Free End Ack (CF +end_ack_)
CF-Ack
CF Ack+CF Poll
CF-Poll

Выдержка из вики———-
В оригинальном 802.11
DCF Distributed Coordination Function, используется чтобы разделить эфир между множеством станций. DCF основывается на CSMA/CA и опционально на 802.11 RTS/CTS, чтобы разделить эфир между станциями. Клиенты управляют пропускной способностью. Это создает несколько ограничений:

-при одновременном взаимодействии большого количества станций происходит множество коллизий, которые снижают общую доступную ширину канала (также как в Ethernet, который использует CSMA/CD).
-нет разделения на трафик по приоритету.
-если станция «выигрывает» доступ к эфиру, она может занимать его столько, сколько ей нужно. И если эта станция имеет низкую пропускную способность (например, 1 Mbit/s), то ей понадобится продолжительное время для передачи данных, и все остальные станции будут страдать от этого.
-и самое важное — это отсутствие гарантий QoS.

Когда точка переходит из режима DCF в режим PCF она посылает beacon длительностью 32768, все точки перестают передавать и больше нет конкуренции за среду.
Point Coordination Function (PCF), она доступна только в режиме «инфраструктуры», в котором станции соединены с сетью через Точку Доступа (Access Point — AP). Этот режим опционален и очень немногие AP и WiFi адаптеры реализуют его. AP посылает «сигнальные» фреймы через постоянные промежутки времени (обычно 0.1 секунды). Между этими фреймами, PCF определяет два периода: Contention Free Period (CFP) и Contention Period (CP). В CP просто используется DCF. А в CFP AP посылает Contention Free — Poll (CF-Poll) пакеты, каждой станции по одному за раз, чтобы дать им право посылать пакеты. AP является координатором. Это позволяет лучше управлять QoS. К несчастью PCF имеет ограниченную поддержку и некоторые ограничения (например, она не определяет классы трафика).

Рассмотрим пример как точка может управлять соединением:
У точки есть данные(DATA) для клиента. Это позволяет клиенту передавать данные (CF-Poll) и подтверждает получение данных клиента (CF-ACK).

802.11e расширяет DCF и PCF, двумя новыми функциями координации: Enhanced DCF (EDCF) и Hybrid Coordination Function (HCF) (HCF может быть названа Enhanced PCF). И EDCF, и HCF определяют Traffic Classes (TC, Классы Трафика). Например, электронные письма могут быть отнесены к трафику с низким приоритетом, а Voice over Wireless IP (VoWIP) к высокому.

С EDCF трафик с высоким приоритетом имеет больший шанс быть отправленным, чем трафик с более низким. В среднем, станция с трафиком более высокого приоритета ждет немного меньше перед отправкой пакета, чем станция с трафиком меньшего приоритета. Реальных гарантий нет, но это наилучший получившийся вариант QoS. В силу легкого применения и настройки, множество людей выбрало эту функцию координации.

HCF работает во многом схоже с PCF: интервалы между сигнальными фреймами делятся на два периода, CFP и CP. Во время CFP, Hybrid Coordinator (HC, обычно AP) контролирует доступ в эфир. А во время CP, все станции функционируют по EDCF. Главное различие от PCF заключается в том, что присутствуют Traffic Classes (TC). Также HC может координировать трафик любым выбранным им способом (а не только циклически). Кроме того станции дают информацию о длине их очередей для каждого TC. HC может использовать эту информацию для того, чтобы дать одной станции больший приоритет. Другое отличие заключается в том, что станциям дается Transmit Opportunity (TXOP): они могут посылать несколько пакетов друг за другом, в выделенный им период времени выбранный HC. Во время CP, HC может оставить себе контроль над доступом в эфир, посылая CF-Poll пакеты станциям. Вкратце, HCF это наиболее продвинутая (и сложная) функция координации. С HCF, QoS может быть настроен очень точно: такие вещи, как контроль пропускной способности, справедливость среди станций, классы трафика, дрожание(джиттер), и многие другие могут быть сконфигурированы в HC.

Любая AP совместимая с 802.11e, должна поддерживать ECDF и HCF. Различие между 802.11e AP-ми будет заключаться в QoS для разных TC: некоторые например, могут поддерживать только базовые возможность настройки контроля пропускной способности, в то время как другие могут пойти дальше и дать возможность контролировать дрожание(джиттер).
—Кусок статьи из вики закончился(дрожание наверное всетаки джиттер)

В режиме экономии энергии клиент сообщает точке о том что он засыпает с помощью null function фрейма. Во время сна клиента, точка буферизирует трафик для клиента. Когда клиент просыпается и видит beacon фрейм с TIM(говорит что для клиента есть буферизированные данные) он запрашивает данные с помощью PS-Poll.

Также точка передает клиентам скорости которые являются обязательными, и клиент должен уметь на них работать, у клиента могут быть и другие скорости, но они не обязательные. Например обязательная скорость =24мбит/с, но точка и клиент могут работать на 54мбит/с, клиент ОБЯЗАН поддерживать скорость 24 мбит/с, но будет работать на максимальной скорости, в данном случае 54. Когда данные отправлены, ACK подтверждение всегда отправляется на одну скорость ниже!

Теперь весь процесс в картинках

1. Точка отсылает beacon каждые 2 секунды
2. Клиент слышит beacon и определяет может ли он соединиться
3. Появляется клиент Б ему не хочется ждать, он посылает probe request

4. Точка отвечает probe response, в котором содержится такая же информация как и в beacon, на основании ответа клиент принимает решение может ли он соединиться или нет.

5. Начиная с этого пункта для двух клиентов будет происходить одно и тоже. Клиент Б шлет запрос на аутентификацию.
6. Точка отвечает клиенту Б, на запрос аутентификации

7. Клиент Б отсылает запрос на присоединение(association)
8. Точка отвечает на запрос

9. Когда клиент хочет послать данные он посылает RTS (предполагается что это смешанная 802.11b/g сеть) с необходимой длительностью
10. Точка отсылает CTS
11. Клиент отсылает данные
12. Точка подтверждает получение каждого фрейма с помощью ACK

13. Клиент посылает фрейм на разрыв соединения
14. Точка отвечает на его запрос
15. Клиент вернулся и посылает сообщение на повторный вход в сеть
16. Точка отвечает на его запрос

Источник

Wi-Fi позиционирование «дешево и сердито». О частоте замеров или возможно ли Wi-Fi позиционирование в реальном времени?

Это третья, пока заключительная статья из серии 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мс, что примерно на порядок меньше пассивного сканирования.

Каждый производитель самостоятельно выбирает тип сканирования и условия его применения. Так же в самой операционной системе может быть опции, позволяющие выбрать определенный режим.

Какую частоту сканирования по 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, очевидно, объединяет такие запросы (и правильно делает), так как счетчик каждую минуту увеличивался на один. Выглядело это примерно так:

Частота замеров в движении

В движении периодичность изменилась и появилась связь с моментом роуминга. Как показал анализатор, действительно, перед моментом роуминга ноутбук слал 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 дней.

Источник