Все о Cisco FastLocation

Чем дальше погружаюсь в тему 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 ^[1].

Данную технологию мы рассматривать не будем, так как сейчас актуальна новая, совершенно переработанная версия FastLocate CMX Release 10.2 ^[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 происходит в весьма неспешной манере и изначально предназначен для обнаружения чужих точек доступа на смежных каналах. Как это работает можно посмотреть здесь ^[3] и здесь ^[4].

К примеру, по умолчанию в диапазоне 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 ^[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

Источник ^[6]