Comments 20
http://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/connected-mobile-experiences/datasheet-c78-734648.html
)
)
мои расчеты, действительно, вписались в заявленные параметры производителя. Но статья не об этом, она немного глубже, в частности она отвечает, почему параметры именно такие и как этим можно попробовать поуправлять. в частности в этом data sheet нет ничего о принципах работы роуминга и как он влияет на частоту замеров и, следовательно точность и достоверность результатов, что я считаю ключевым моментом для понимания данной темы. Я вижу здесь весьма общую фразу «Devices can send probe packets very infrequently. Up to 90 seconds (client dependent)», что совершенно недостаточно для понимания сути процесса.
Ну строго говоря в даташите и не должно быть технических подробностей, только маркетинговые (завышенные) цифры. Но в принципе влияние экономии батарей и роуминга на точность позиционирования лежит на поверхности. У cisco уже довольно давно есть технология clientlink, которая по сути и есть технология позиционирования, так что выкат технологий позиционирования wi-fi был лишь вопросом времени.
P.S. В Шереметьево используется система позиционирования клиентов на основе беспроводного протокола… Bluetooth. На редкость сумрачное решение, но как не странно на мой взгляд лучше приспособлено для отслеживания клиентов.
P.S. В Шереметьево используется система позиционирования клиентов на основе беспроводного протокола… Bluetooth. На редкость сумрачное решение, но как не странно на мой взгляд лучше приспособлено для отслеживания клиентов.
1. То, что при роуминге посылается на все каналы Probe Request, я бы не сказал, что лежит на поверхности. Я не так много видел материалов, где про это упоминается. Ни в экзаменах Cisco, ни в CWNP треках я этого не видел. Это не так уж и очевидно. Намного очевидней, что используется протокол 802.11k, который входит в IEEE 802.11-2012 для роуминга.
2. ClientLink основывается на передаче одного сигнала в разных фазах с разных антенн с целью совмещения фаз на приёмнике и с моей точки зрения эта технология никак не связана с технологией позиционирования, которая основывается на RSSI триангуляции — получение замеров мощности сигнала клиента с трех точек, чья геопозиция заранее известна ( см. первую статью).
3. Есть много задач, которые может решать позиционирование и много технологий позиционирования с разной точностью. Наиболее наглядно это можно посмотреть, к примеру здесь на графике 6.
Моя задача была показать, на что способно именно Wi-Fi позиционирование без применения доп. оборудования.
Bluetooth Low Energy (BLE) решает вполне определенные, по моему мнению довольно узкие задачи (и решает достаточно хорошо), его я тоже планирую коснуться в своих статьях.
2. ClientLink основывается на передаче одного сигнала в разных фазах с разных антенн с целью совмещения фаз на приёмнике и с моей точки зрения эта технология никак не связана с технологией позиционирования, которая основывается на RSSI триангуляции — получение замеров мощности сигнала клиента с трех точек, чья геопозиция заранее известна ( см. первую статью).
3. Есть много задач, которые может решать позиционирование и много технологий позиционирования с разной точностью. Наиболее наглядно это можно посмотреть, к примеру здесь на графике 6.
Моя задача была показать, на что способно именно Wi-Fi позиционирование без применения доп. оборудования.
Bluetooth Low Energy (BLE) решает вполне определенные, по моему мнению довольно узкие задачи (и решает достаточно хорошо), его я тоже планирую коснуться в своих статьях.
1. То что на все каналы — нет, но что при роуминге на точку доступа должен идти probe request вполне ожидаем.
2. Beamforming по сути дает нам вектор на клиента. Используя информацию такого рода с трех точек мы по сути получаем ту же триангуляцию. Другой вопрос что конкретно clientlink никто для геопозиционирования (насколько мне известно по крайней мере) не использует. Точно так же как на основе wi-fi c несколькими антеннами можно построить эрзац радар для отслеживания положения людей, это было не более чем обобщение, а не конкретное предложение по реализации.
3. Не спорю. Строго говоря я ни с чем в статье особо не спорю, скорее скептически отношусь к использованию хорошей технологии для задач, для которых она не предназначена. Ну право слово, как орехи микроскопом…
2. Beamforming по сути дает нам вектор на клиента. Используя информацию такого рода с трех точек мы по сути получаем ту же триангуляцию. Другой вопрос что конкретно clientlink никто для геопозиционирования (насколько мне известно по крайней мере) не использует. Точно так же как на основе wi-fi c несколькими антеннами можно построить эрзац радар для отслеживания положения людей, это было не более чем обобщение, а не конкретное предложение по реализации.
3. Не спорю. Строго говоря я ни с чем в статье особо не спорю, скорее скептически отношусь к использованию хорошей технологии для задач, для которых она не предназначена. Ну право слово, как орехи микроскопом…
1. В этом то и весь смысл, что на все каналы, без этого бы позиционирование не работало.
Да и по поводу того, что именно _должен_ идти probe request я бы тоже поспорил. Что мешает слушать beacon пакеты ( в которых содержится точно такая же информация), которые идут с периодичностью 102.4мс независимо ни от чего от точки? Понятно, что сравнительно редко, но их можно услышать задолго до момента роуминга.
2. Beamforming даёт представление _только_ о смещениях фаз сигнала на разных антеннах. На самом деле больше ничего ему и не надо. Он понятия не имеет о геопозиции сигнала.
Я ничего не нашел в описанииTxBF, который входит в стандарт 802.11n, применительно к позиционированию.
3. Я хочу сказать, что не бывает плохой технологии. Для каждой технологии есть подходящая задача, нужно просто найти правильную технологию и правильно определить задачу :) Вы правильно заметили про орехи и микроскоп. Тут как раз идея стоит в том, чтобы найти правильную задачу для микроскопа (или молотка).
Данной точности позиционирования Wi-Fi вполне достаточно для общего отслеживания местоположения и перемещения клиентов, но не очень достаточно для отслеживания перемещения клиентов в реальном времени, это да.
Да и по поводу того, что именно _должен_ идти probe request я бы тоже поспорил. Что мешает слушать beacon пакеты ( в которых содержится точно такая же информация), которые идут с периодичностью 102.4мс независимо ни от чего от точки? Понятно, что сравнительно редко, но их можно услышать задолго до момента роуминга.
2. Beamforming даёт представление _только_ о смещениях фаз сигнала на разных антеннах. На самом деле больше ничего ему и не надо. Он понятия не имеет о геопозиции сигнала.
Я ничего не нашел в описанииTxBF, который входит в стандарт 802.11n, применительно к позиционированию.
3. Я хочу сказать, что не бывает плохой технологии. Для каждой технологии есть подходящая задача, нужно просто найти правильную технологию и правильно определить задачу :) Вы правильно заметили про орехи и микроскоп. Тут как раз идея стоит в том, чтобы найти правильную задачу для микроскопа (или молотка).
Данной точности позиционирования Wi-Fi вполне достаточно для общего отслеживания местоположения и перемещения клиентов, но не очень достаточно для отслеживания перемещения клиентов в реальном времени, это да.
1. В принципе ничто, кроме CAPWAP) Насколько помню он должен обязательно отдать probe response в split mac mode.
2. Из дельты фаз и известной базы антенн можно получить направление.
3. Wi-fi шикарная технология, но использовать ее текущую реализацию для позиционирования не стоит. Скажем лучше выпустить драфт rfc 802.11XXX с новым фреймом, который отправляется по всем каналам каждые n мс иииии… получить умирающую за час батарею девайса. Это не плохо если можно определить позицию по wi-fi. Плохо что вообще возникло желание определять позицию по wi-fi, это говорит о том, что бизнес зашел в тупик — есть спрос на предложение, но нет его вменяемой реализации. А Cisco и Extreme networks (вроде у них тоже есть такая вещь, но могу и наврать) сейчас соревнуются в «мой микроскоп ухватистее на 10% и на 15% тяжелее конкурента!»
Но все вышенаписанное сугубо мое имхо, на лавры гуру я не претендую.
2. Из дельты фаз и известной базы антенн можно получить направление.
3. Wi-fi шикарная технология, но использовать ее текущую реализацию для позиционирования не стоит. Скажем лучше выпустить драфт rfc 802.11XXX с новым фреймом, который отправляется по всем каналам каждые n мс иииии… получить умирающую за час батарею девайса. Это не плохо если можно определить позицию по wi-fi. Плохо что вообще возникло желание определять позицию по wi-fi, это говорит о том, что бизнес зашел в тупик — есть спрос на предложение, но нет его вменяемой реализации. А Cisco и Extreme networks (вроде у них тоже есть такая вещь, но могу и наврать) сейчас соревнуются в «мой микроскоп ухватистее на 10% и на 15% тяжелее конкурента!»
Но все вышенаписанное сугубо мое имхо, на лавры гуру я не претендую.
Давайте попробуем разобраться.
1. Чтобы упростить ситуацию, предлагаю начать с того, что решение о роуминге принимает Клиент. То, насколько быстро это произойдет, зависит от инфраструктуры, но это нас в данной задаче не волнует. Клиент понятия не имеет, что такое CAPWAP, поэтому то, как он работает, для клиента не имеет никакого значения.
Протокол CAPWAP определяет взаимодействие контроллера и точки, забирая на себя некоторые функции DSS (distribution system services), к механизму роуминга сам по себе этот протокол отношения не имеет.
То, что на probe request точка доступа должна отдать probe response — это верно, но это верно для любой архитектуры, контроллерной, автономной. И это тоже в общем к самому процессу роуминга отношения не имеет.
Изначально в стандарте определяются следующие требования к роумингу:
1. Клиент должен послать Reassociation request той точке, куда хочет подключиться
2. Точка должна ответить Reassociation response ( разрешить подключиться или нет).
То, каким образом Клиент выбирает точку, к которой хочет подключиться не определено в стандарте. И это ключевой момент!
Каждый производитель сам решает, как это делать. Так сложилось, что перед самим моментом роуминга клиенты часто посылают probe request на все каналы и слушают ответы, чтобы видимо окончательно обновить таблицу характеристик точек доступа, куда можно сделать роуминг и уже окончательно решить, куда слать Reassociation request. Мне этот подход кажется достаточно топорным. В самом начале становления этой технологии это еще проходило, но сейчас видно, что производители сами пытаются этот механизм оптимизировать.
2. Механизм ClientLink основан на том, что сигналы, передающиеся с разных антенн физически разнесены, у них разные физические пути. Мы не имеем понятия о траектории путей (тут могут быть отражения, преломления, затухание сигнала и многое другое, что конечно влияет так же и на фазу), вариантов таких траекторий очень много. Если бы мы знали траекторию, то, возможно, мы могли бы как-то предположить расстояние до Клиента, но так как мы траекторию не знаем, то и только на основе фаз рассчитать траекторию и расстояние не удастся.
3. Я бы хотел тут отметить несколько моментов
а) позиционирование — это не сервис, это инструмент, можно сказать, что это транспорт для сервисов. Сервис определяет требования к транспорту. Я уже перечислил несколько сервисов, которым достаточно транспорта Wi-Fi позиционирования.
б) я вообще говорю о Wi-Fi позиционировании «дешево и сердито», когда вы, устанавливая одну виртуальную машину ( стоимость этой машины ну 5% от стоимости инфраструктуры, может меньше), получаете достаточно мощный инструмент, который может использоваться для систем wIPS, для беспроводной аналитики, других задач. За 5% вы получаете представление о местонахождении и передвижении беспроводных пользователей, да, не с точностью до метра и не в реальном времени, но все равно, этой информации много для чего хватает.
в) нужно понимать разницу между определением местоположения персональных wi-fi клиентов и специализированных wi-fi устройств. как я писал, решения о позиционировании активных wi-fi меток очень неплохо себя зарекомендовало. Они посылают только строго probe request и строго один раз в определенный промежуток времени. Работают до месяца автономно. Это очень неплохо. Если промежутки времени уменьшить до секунд, мы получим позиционирование в реальном времени.
1. Чтобы упростить ситуацию, предлагаю начать с того, что решение о роуминге принимает Клиент. То, насколько быстро это произойдет, зависит от инфраструктуры, но это нас в данной задаче не волнует. Клиент понятия не имеет, что такое 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 и строго один раз в определенный промежуток времени. Работают до месяца автономно. Это очень неплохо. Если промежутки времени уменьшить до секунд, мы получим позиционирование в реальном времени.
Все-таки не понял ваш ответ по поводу ClientLink (BeamForming). Это же по определению формирование диаграммы направленности в сторону клиента (достигаемое при помощи сдвига фазы на нескольких антеннах, как в большой ФАР).
Т.е. мы приблизительно знаем азимут клиента! А это уже AoA. Но последнее требует дорогих точек. Хотя первое выполняется на 1 и 2 серии.
непонятно, почему ((
Т.е. мы приблизительно знаем азимут клиента! А это уже AoA. Но последнее требует дорогих точек. Хотя первое выполняется на 1 и 2 серии.
непонятно, почему ((
Как я понимаю, азимут знать не обязательно, достаточно знать, как нужно сдвинуть фазы на разных антеннах на передачу. А эту информацию мы получаем, когда мы получаем пакеты на приём от клиента и используем симметричную технологию MRC, когда подстраиваем фазу на приёме. Сдвиг фаз на приём и передачу симметричен.
А разве по сдвигу фаз нельзя приблизительно определить азимут?
я подозреваю, что нет. тогда бы Cisco не использовала для этого большие дорогие блоки антенн — www.iptel.com.au/cisco-hyperlocation-module.html.
Ну во-первых там точность существенно разная. модуль гиперлокации содержит несколько десятков антенн, позволяющих более точно определить азимут.
А во-вторых — надо же вендору жить на что-то. Cisco очень не любит наделять старые устройства новым функционалом, пусть и на словах говорит обратное.
А во-вторых — надо же вендору жить на что-то. Cisco очень не любит наделять старые устройства новым функционалом, пусть и на словах говорит обратное.
1) ClientLink относится к категории «On-Chip Beamforming». Чипсет координирует передачу на разные антенны, стараясь получить синфазный сигнал на приёмной стороне. Я не нашел в описании ссылок на то, как применяется в этом случае азимут. Знание азимута помогает при определении местоположения несколькими точками клиента, но так как требований вешать точки в определенном направлении нет, то азимут не может использоваться для этого.
2) У меня тоже полно скепсиса, но, тут, позвольте, не согласиться. Практика, по крайней мере в беспроводных сетях, говорит об обратном. Основной релиз сейчас 8.0, а этот релиз поддерживают точки 1130 и 1240, выпускаемые с 2006 года. Самая новая линейка точек Cisco х8хх требует ПО 8.2, его уже поддерживают точки следующего поколения, начали выпускаться которые с 2011 года (1140, 1260 и т.д. — первые 802.11n точки).
Если потребуется ставить новые точки доступа, потребуется релиз 8.2, то есть потребуется менять точки, купленные в 2006 году, но купленные в 2011 будут работать. По-моему неплохая преемственность.
За это время Juniper успела купить и убить Trapeza, Motorolla успела побывать в нескольких руках, осев в Extreme Networks, у которой и так недавно куплен Enterasys, и теперь у них две линейки. Aruba купил HPE и как минимум это не выглядит позитивным. Ruckus тоже купили. Не вижу ни одного корпоративного вендора, который долбил бы свою линейку с 2005 года (Cisco купила Airespace в 2005) без перекупок.
2) У меня тоже полно скепсиса, но, тут, позвольте, не согласиться. Практика, по крайней мере в беспроводных сетях, говорит об обратном. Основной релиз сейчас 8.0, а этот релиз поддерживают точки 1130 и 1240, выпускаемые с 2006 года. Самая новая линейка точек Cisco х8хх требует ПО 8.2, его уже поддерживают точки следующего поколения, начали выпускаться которые с 2011 года (1140, 1260 и т.д. — первые 802.11n точки).
Если потребуется ставить новые точки доступа, потребуется релиз 8.2, то есть потребуется менять точки, купленные в 2006 году, но купленные в 2011 будут работать. По-моему неплохая преемственность.
За это время Juniper успела купить и убить Trapeza, Motorolla успела побывать в нескольких руках, осев в Extreme Networks, у которой и так недавно куплен Enterasys, и теперь у них две линейки. Aruba купил HPE и как минимум это не выглядит позитивным. Ruckus тоже купили. Не вижу ни одного корпоративного вендора, который долбил бы свою линейку с 2005 года (Cisco купила Airespace в 2005) без перекупок.
У меня сформировался ответ по поводу того, стоит ли использовать технологию Wi-Fi позиционирования. Ответ — стоит. Почему? Если говорить о подсистеме wIPS, то нам в первую очередь нужно найти устройство (вражеское, своё, точку, клиента). И для этой задачи имеющихся характеристик достаточно.
Для Wi-Fi аналитики вопрос открытый, для каких-то задач достаточно, для каких-то нужно добавлять модули мониторинга для получения позиционирования в реальном времени.
Для Wi-Fi аналитики вопрос открытый, для каких-то задач достаточно, для каких-то нужно добавлять модули мониторинга для получения позиционирования в реальном времени.
Спасибо за статью.
Если в классическом 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.»
Если в классическом 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.»
Добрый день! Я помню ваш комментарий и обсуждение по поводу Probe Request, я даже хотел написать в обсуждение, что вот написал статью, но вы меня опередили. По поводу iOS 9 честно не тестировал. Судя по описанию, могу предположить, что, если он будет подключен к сети, то вести он себя будет аналогично Android. Если же устройство не подключено (not associated) то по всей видимости отследить историю перемещения устройства просто так мы не сможем. Сейчас я уже закончил испытания и у меня кончилась временная лицензия :(, но я постараюсь не забыть это потестировать, когда в следующий раз займусь стендом.
Спасибо, будет интересно увидеть поведение iOS на практике.
Со своей стороны попробую послушать эфир снифером (у нас есть несколько iPhone у коллег в офисе), но у нас только одна точка доступа и как работает роуминг я не увижу.
Кстати Apple пишет что iOS уже поддерживает 802.11k, 802.11r и 802.11v:
https://support.apple.com/ru-ru/HT202628
Со своей стороны попробую послушать эфир снифером (у нас есть несколько iPhone у коллег в офисе), но у нас только одна точка доступа и как работает роуминг я не увижу.
Кстати Apple пишет что iOS уже поддерживает 802.11k, 802.11r и 802.11v:
https://support.apple.com/ru-ru/HT202628
Sign up to leave a comment.
Wi-Fi позиционирование «дешево и сердито». О частоте замеров или возможно ли Wi-Fi позиционирование в реальном времени?