Чем дальше погружаюсь в тему Wi-Fi позиционирования, тем очевиднее становится факт, что основная задача заключается не в достижении необходимой точности, а в получении необходимого количества замеров! Почему я так думаю?
Требования к плотности размещения точек доступа с каждым годом увеличиваются, что положительно сказывается на точности позиционирования, а вот частота замеров по Probe Request не становится выше, скорее наоборот.
В связи с этим многие производители разработали свои собственные инструменты для увеличения частоты замеров. Традиционно, одним из инноваторов в этой области выступает компания Cisco, которая вывела на рынок инструмент под названием Cisco FastLocation.
Давайте попробуем разобраться во всех нюансах этого инструмента.
FastLocate = Data RSSI
Для начала что же подразумевается под маркетинговыми словами Cisco FastLocate? Если совсем кратко, то это замер уровня сигнала (RSSI) не по management пакетам Probe Request, а по пакетам данных (data). Такой режим замера называется “Data RSSI” (в дополнение к “Probe RSSI”). Далее в статье я буду использовать в зависимости от контекста и тот и другой термин.
FastLocate Release 8.0 vs FastLocate Release 10.2
Технология Cisco FastLocation появилась в 2014 году, когда система позиционирования Cisco начала сильно эволюционировать.
На тот момент она имела достаточно ограниченный функционал, поддерживалась только на специально установленных модулях мониторинга WSM (Wireless Security Module), которые устанавливались в модульные, то есть топовые офисные точки доступа. Это была так называемый FastLocate MSE Release 8.0.
Данную технологию мы рассматривать не будем, так как сейчас актуальна новая, совершенно переработанная версия FastLocate CMX Release 10.2.
Именно её мы будем тестировать с использованием контроллера Cisco WLC 2504 с версией ПО 8.1.131.20 и точек серии Cisco Aironet 3602.
FastLocate без использования дополнительных модулей
Первый вопрос, который мне пришел в голову: можно ли делать Data RSSI без использования дополнительных модулей? В арсенале Cisco уже есть возможность перевести точку доступа в режим мониторинга (сканирования) всех каналов, есть гибридный режим работы, когда точка обслуживает как пользователей, так и сканирует смежные каналы. Можем ли мы использовать эти режимы для Data RSSI?
FastLocate в гибридном режиме ELM
Если в 8-й версии CMX такое было невозможно, то к 10-й версии CMX такая опция появилась. У точек доступа Cisco есть специальный режим работы Enhanced Local Mode (ELM), в котором помимо обслуживания клиентов, точка доступа выполняет так называемый Off-Channel Scanning, то есть сканирует смежные каналы. Это происходит не без потери производительности, которая составляет порядка 15%.
Off-Channel Scanning при выключенном FastLocate
Off-Channel Scanning происходит в весьма неспешной манере и изначально предназначен для обнаружения чужих точек доступа на смежных каналах. Как это работает можно посмотреть здесь и здесь.
К примеру, по умолчанию в диапазоне 2.4ГГц настроено сканирование всех каналов и интервал полного сканирования 180с. В данном режиме точка доступа каждые 180/13=14 секунд прерывается на 50мс на сканирование смежного канала (на переход в каждую сторону так же тратиться 10мс). Картина выглядит примерно вот так:
Работу данного алгоритма можно проверить непосредственно на точке доступа при помощи команды debug dot11 do0 trace print channel
Hyperlocation_2#debug dot11 do0 trace print channel
Oct 4 10:09:37.909: CC0CDA4C-0 Channel 8 (2447) promiscuous 20MHz
Oct 4 10:09:37.957: CC0D772F-0 Channel 11 (2462) 20MHz
Oct 4 10:09:50.753: CCD0DEF8-0 Channel 9 (2452) promiscuous 20MHz
Oct 4 10:09:50.801: CCD17BD3-0 Channel 11 (2462) 20MHz
Oct 4 10:09:53.955: CD948399-0 Channel 10 (2457) promiscuous 20MHz
Oct 4 10:09:53.999: CD951CFD-0 Channel 11 (2462) 20MHz
Oct 4 10:10:06.763: CE57FEC4-0 Channel 11 (2462) promiscuous 20MHz
Oct 4 10:10:06.811: CE589BA7-0 Channel 11 (2462) 20MHz
По данному выводу можно увидеть, что периодичность сканирования порядка 13 секунд, что сходится с документацией. Применение Data RSSI в таком режиме было бы не очень эффективно (забегая вперед скажу, что он и не используется).
Off-Channel Scanning при включенном FastLocate
Если на беспроводном контроллере активировать FastLocate, то Off-Channel Scanning начинает работать несколько иначе.
Hyperlocation_2#debug dot11 do0 trace print channel
Oct 4 10:05:40.887: BDEC139E-0 Channel 12 (2467) promiscuous 20MHz
Oct 4 10:05:40.967: BDED365C-0 Channel 11 (2462) 20MHz
Oct 4 10:05:43.691: BE16D8E7-0 Channel 13 (2472) promiscuous 20MHz
Oct 4 10:05:43.771: BE17FBC2-0 Channel 11 (2462) 20MHz
Oct 4 10:05:46.775: BE45D2A0-0 Channel 11 (2462) 20MHz
Oct 4 10:05:46.983: BE4919C1-0 Channel 14 (2484) promiscuous listen_only 20MHz
Oct 4 10:05:47.063: BE4A3D27-0 Channel 11 (2462) 20MHz
Oct 4 10:05:49.795: BE7407C6-0 Channel 1 (2412) promiscuous 20MHz
Oct 4 10:05:49.879: BE75291D-0 Channel 11 (2462) 20MHz
Временные интервалы уменьшаются до трех секунд. Технической документации в части того, как работает Off-Channel Scanning при активированном FastLocate я не нашел, но исходя из приведенного вывода можно сделать вывод, что время сканирования составляет так же порядка 50 мс ( 967-887 = 80 мс, это 50-60 мс на сканирование + 10 мс на переключение между каналами).
Очевидно, уменьшение временных интервалах было сделано для улучшения работы механизма FastLocation.
Зависимость Off-Channel Scanning от режима работы wIPS
Точка доступа может работать с локальным или централизованным wIPS (системой обнаружения и предотвращения вторжений), что регулируется настройкой на точке доступа. Тестируя Off-Channel Scanning в разных режимах работы wIPS я не увидел отличий.
FastLocate в режиме Monitor
Еще до появления технологии FastLocate точки доступа умели работать в режиме Monitor mode AP. Этот режим использовался для централизованной системы обнаружения вторжений. При переходе в этот режим оба радиомодуля перестают обслуживать клиентов и последовательно сканируют каналы с продолжительностью 1.2 секунды.
Данный алгоритм работы подтверждается выводом с точки доступа:
pod1-1140#debug dot11 do0 trace print channel
*Oct 4 10:51:22.031: 1FB01CC6-0 Channel 12 (2467) promiscuous 20MHz
*Oct 4 10:51:23.246: 1FC2A970-0 Channel 13 (2472) promiscuous 20MHz
*Oct 4 10:51:24.458: 1FD5283F-0 Channel 14 (2484) promiscuous listen_only 20MHz
*Oct 4 10:51:25.670: 1FE7A716-0 Channel 1 (2412) promiscuous 20MHzВ случае Monitor mode AP алгоритм работы не менялся при включении/выключении FastLocate.
FastLocate работает только для подключенных клиентов
При использовании режима Monitor есть нюанс: FastLocate работает только для подключенных к инфраструктуре клиентов, а при переводе точки доступа в режим Monitor точка перестаёт обслуживать клиентов. То есть подразумевается, что в инфраструктуре будут другие точки доступа, обслуживающие клиентов.
Точки доступа в режиме Monitor предлагается размещать в пропорции 1:5 к обычным точкам доступа.
FastLocate с использованием дополнительного модуля WSM
Это основной режим работы FastLocate, который предусматривает установку в точки доступа модулей WSM в пропорции 2:5 (то есть как минимум 2:5 точек доступа должны быть модульные, то есть самые топовые).
WSM имеет свой собственный алгоритм работы. WSM модуль в отличии от радио в режиме мониторинга сканирует канал не по 1.2 секунды, а по 250 мс. Но он это делает не последовательно, а в соответствии с определенными правилами:
<L1, L1, L1, L1, L1, CA, L2>
It will scan 5 slots of L1(serving channel of the APs) followed by a cleanAir slot (if enabled), followed by one slot of L2 (channels in the country/DCA list). If there are less than 5 channels in the L1 list, the same channels will be scanned repeatedly till the 5 L1 slots are filled up.
Можно сказать, что большой приоритет отдаётся инфраструктурным каналам (на которых работают свои точки доступа), что и понятно, потому что FastLocation работает только для подключенных клиентов и сканирование смежных каналов не так важно.
Как этот алгоритм выглядит при выводе на точке доступа:
Sep 20 16:24:17.824: 2EC10B2D-2 Channel 1 (2412) promiscuous 20MHz
Sep 20 16:24:17.903: 2EC24019-2 Channel 48 (5240) promiscuous 20MHz
Sep 20 16:24:18.151: 2EC60A5D-2 Channel 6 (2437) promiscuous 20MHz
Sep 20 16:24:18.383: 2EC99BD3-2 Channel 11 (2462) promiscuous 20MHz
Sep 20 16:24:18.627: 2ECD54AC-2 Channel 1 (2412) promiscuous 20MHz
Sep 20 16:24:18.895: 2ED16A1E-2 Channel 161 (5805) promiscuous 20MHz
Sep 20 16:24:19.435: 2ED99B31-2 Channel 6 (2437) promiscuous 20MHz
Sep 20 16:24:19.555: 2EDB7010-2 Channel 60 (5300) promiscuous 20MHz
Sep 20 16:24:19.807: 2EDF53C5-2 Channel 48 (5240) promiscuous 20MHz
Sep 20 16:24:20.046: 2EE2EF52-2 Channel 6 (2437) promiscuous 20MHz
Sep 20 16:24:20.282: 2EE695CB-2 Channel 11 (2462) promiscuous 20MHz
Sep 20 16:24:20.514: 2EEA16E6-2 Channel 1 (2412) promiscuous 20MHz
Sep 20 16:24:21.010: 2EF1B48A-2 Channel 11 (2462) promiscuous 20MHz
Sep 20 16:24:21.166: 2EF40C9B-2 Channel 161 (5805) promiscuous 20MHz
Sep 20 16:24:21.454: 2EF86DA9-2 Channel 60 (5300) promiscuous 20MHz
Sep 20 16:24:21.710: 2EFC5A8F-2 Channel 48 (5240) promiscuous 20MHz
Sep 20 16:24:21.929: 2EFFBC42-2 Channel 6 (2437) promiscuous 20MHz
Sep 20 16:24:22.161: 2F033F09-2 Channel 11 (2462) promiscuous 20MHz
Sep 20 16:24:22.645: 2F0AA07D-2 Channel 36 (5180) promiscuous 20MHz
Sep 20 16:24:22.785: 2F0CCDC0-2 Channel 1 (2412) promiscuous 20MHz
Sep 20 16:24:23.061: 2F10F3CB-2 Channel 161 (5805) promiscuous 20MHz
Sep 20 16:24:23.337: 2F1539E8-2 Channel 60 (5300) promiscuous 20MHz
Sep 20 16:24:23.593: 2F192133-2 Channel 48 (5240) promiscuous 20MHz
Sep 20 16:24:23.813: 2F1C798A-2 Channel 6 (2437) promiscuous 20MHz
Sep 20 16:24:24.297: 2F23E056-2 Channel 48 (5240) promiscuous 20MHz
Sep 20 16:24:24.433: 2F25EE6C-2 Channel 11 (2462) promiscuous 20MHz
Sep 20 16:24:24.673: 2F299DFA-2 Channel 1 (2412) promiscuous 20MHz
Sep 20 16:24:24.937: 2F2D9ABB-2 Channel 161 (5805) promiscuous 20MHz
Sep 20 16:24:25.221: 2F31F49A-2 Channel 60 (5300) promiscuous 20MHz
Sep 20 16:24:25.473: 2F35CF9A-2 Channel 48 (5240) promiscuous 20MHz
Sep 20 16:24:25.977: 2F3D7AA1-2 Channel 40 (5200) promiscuous 20MHz
Sep 20 16:24:26.097: 2F3F532D-2 Channel 6 (2437) promiscuous 20MHz
Sep 20 16:24:26.329: 2F42D521-2 Channel 11 (2462) promiscuous 20MHz
Интервал сканирование не такой ровный, как в других режимах, и находится в пределах 50-250мс.
И действительно, не инфраструктурные каналы (в моём случае это каналы 36, 40) обходились достаточно редко, с периодичностью более 3 секунд, что так же можно увидеть в логах.
Оценка частоты замеров
При активации режима FastLocation частота замеров напрямую зависела от активности клиента. Если клиент (смартфон, телефон, ноутбук) находились в спящем режиме, то есть не использовался активно Wi-Fi адаптер, частота замеров была сравнима с методом Probe RSSI. Если же устройство использовало активно Wi-Fi адаптер, то частота замеров резко возрастала.
Я не стал тестировать все возможные схемы работы Cisco FastLocation, так как есть очень много факторов, влияющих на частоту замеров, как со стороны инфраструктуры, так и со стороны клиента, поэтому тесты проводились только в режиме WSM.
Использовалось три типа устройств: смартфон, планшет и ноутбук. Для всех тестируемых устройств интервал между замерами был соизмерим и составлял порядка 2-6 секунд при активном использовании Wi-Fi адаптера.
Общие выводы
1. FastLocate (Data RSSI) по сравнению с Probe RSSI в общем случае для персональных устройств позволяет значительно увеличить частоту замеров, особенно при использовании Wi-Fi модуля.
2. Но если клиентское устройство находится в спящем режиме и не использует Wi-Fi адаптер, частота замеров падает до стандартной при Probe RSSI.
3. Очень сложно говорить о каком-то конкретном значении частоты замеров в случае использования Wi-Fi позиционирования для персональных устройств. Есть очень много факторов, как со стороны инфраструктуры, так и со стороны клиента, влияющих на данную характеристику. Для получения конкретных значений, я полагаю, надо действовать по аналогии с радиообследованием, то есть проводить полевые испытания всей системы целиком и с требуемыми клиентскими устройствами.
Автор: openalex
