Большое спасибо за вопрос. Я ведь для статьи копал в эту сторону и у меня даже есть что сказать, но, пока писал, этот момент я упустил. Я этот момент распишу тогда в следующей статье, тем более к следующей статье это так же имеет отношение.
Cisco в своей прошлой версии позиционирования (до версии 8.0) использовало две технологии: триангуляцию и Fingerprint. Благодаря этому в частности до восьмой версии включительно был так же доступен механизм калибровки.
В новой версии ( CMX 10) механизм калибровки отсутствует, я спрашивал у консультанта Cisco, ответ был такой, что это потому что технология Fingerprint теперь не используется. К сожалению, документация по 10-й версии пока не такая подробная. Поэтому я пока делаю вывод, что в 10-й версии используется только триангуляция.
Почему отказались от Fingerprint открыто не объясняется. Я подозреваю, либо потому что не сделали ( так как 10-я версия — это полностью новый продукт), либо потому что проявились какие-то тяжелорешаемые проблемы. Мне было бы самому интересно узнать ответ на этот вопрос.
Заявленная точность у Cisco обеспечивается с учетом планирования покрытия под позиционирование (основное требование — в каждой точке пространства должен быть сигнал -75dBm и более от трех точек доступа), то есть точек будет в раза два больше, чем обычно.
Навес HALO ( модуль и антенна) в GPL стоит около 1000$ и точка должна быть модульная, серия 3ххх, то есть дорогая. При этом для достижения точности 1м требования к покрытию остаются!
Видео занятное, посмотрю и почитаю, спасибо!
У меня сейчас стенд развернут с HALO, я следующей статьёй постараюсь разобраться с ним…
Да, сейчас есть попытки активного продвижения BLE (Bluetooth low-energy) разными производителями типа Cisco, HPE/Aruba и др.
Новые точки доступа комплектуются BLE beacon-ом.
Про это я надеюсь получится рассказать чуть позже в отдельной статье.
В некоторых системах позиционирования есть калибровщики. Но, к примеру, в Cisco CMX калибровщика нет и пока не планируется, я этот вопрос специально узнавал.
Беспроводной адаптер точно собирает служебную информацию для каждого пакета, которая включает в себя date and
time stamps, a channel stamp, signal stamp, and a noise stamp. В анализаторе пакетов эта информация находится в отдельном заголовке, типа Radiotap Header. Если это делает клиентский адаптер, то точка доступа это наверняка может делать и скорее всего делает при необходимости.
Probe request посылается клиентом в самом начале общения с точкой, далее этот тип management фрейма не используется, поэтому замерять уровень сигнала только этих пакетов бесполезно для позиционирования.
К тому же ассоциированное устройство вроде как больше не должно посылать что либо другим точкам.
Как тогда будет работать трилатерация?
Да, это известная проблема, которую я немножко затронул в статье. Во-1, к примеру, точка Cisco (да я думаю большинство) небольшую часть времени тратит на сканирование всех каналов. Можно не попасть на пакет клиента. Поэтому используют дополнительное радио, которое все время занимается только тем, что сканирует каналы, но опять же, приходится перебирать каналы. Чуть проще, когда требуется позиционировать только подключенных клиентов, перебирать каналов приходится в этом случае меньше ( к примеру только 1-6-11 в диапазоне 2.4 ГГц).
Я этот вопрос постараюсь раскрыть в следующей статье, вместе с описанием FastLocation.
спасибо, интересный опыт. а можете дать ссылку на сайт компании, может там что написано? Или какие-нибудь названия производителей, я поищу информацию. Ну в общем что-нибудь, чтобы можно было погуглить.
Насколько я понимаю, та же Cisco использует мультилатерацию, так как говорит, что желательно иметь 4 замера. При этом явно указывает, что позволяет добиться в 90% случаев точности 10м и в 50% случаев точности 5м. Могу еще сказать, что похоже Cisco возлагает надежду на AoA. Про алгоритм Левенберга-Марквардта с комбинацией фильтров не могу ничего сказать, к сожалению, посмотрю, спасибо!
Я полагаю, что уровень сигнала замеряется для каждого пакета, который услышала точка. Другое дело, что далеко не все точки слышат каждый пакет клиента, так как он передаётся на определенном канале, а точки слушают в основном каждая свой.
Probe request используются только в весьма определенных обстоятельствах, а именно в момент активного сканирования беспроводной среды. В Probe request может быть указан какой-то конкретный SSID, тогда точки с этим SSID возвращают probe response, либо не указан SSID, тогда все точки, что услышали этот запрос, возвращают параметры всех имеющихся SSID.
Что касается iOS9, то полагаю, что это может иметь значение для неассоциированных устройств, тогда действительно будет сложнее отслеживать положения устройств, которые не подключились к беспроводной сети.
А можете сказать, какие конкретно таги использовались в каждом конкретном случае на базе каких Wi-Fi решений это строилось. Было бы очень интересно узнать.
Тоже думал о применимости компаса, акселомтра в тандеме с BLE: достаточно несколько реперных точек ( а не ровный слой по всему зданию) и начинаем считать.
Да, все это имеет место быть.
У всех телефонов же разные антенны, не уверен, что они передают в служебных пакетах их характеристики (что могло бы немного облегчить расчет).
По поводу того, где держит телефон человек — это действительно очень сильно влияет. Я вот думаю, что в этом случае ситуацию может чуть поправить AoA: данные об углах у нас не должны меняться и клиент теоретически не должен уж сильно «скакать» с места на место при перемещении телефона от левого уха в правый карман.
А для этого обязателен Wi-Fi вообще на телефоне? Может быть достаточно идентификатора телефона или SIM карты, перемещение которых отслеживать?
Для Wi-Fi, в принципе, чтобы отслеживать потоки, не обязательно даже делать CP и заносить данные, можно отслеживать MAC адреса ( для этого клиентам даже не надо подключаться к сети, достаточно отправить пару probe request-ов. К этому можно еще добавить DHCP profiling и HTTP profiling и тоже добавлять к данным о MAC адресе ( тип устройства, тип ОС..)
Да, наверно не стоило ссылаться на GPS. Хоть они и используют трилатерацию, формула расчета расстояния действительно кардинально разные. Если в GPS время распространения сигнала всегда постоянная и формула получается линейная, то в Wi-Fi сила сигнала уменьшается нелинейно и зависимость квадратичная. То есть увеличение расстояний на точность GPS позиционирования не влияет, а вот на точность Wi-Fi позиционирования влияет очень сильно.
Согласен про наличии большого числа нюансов в физической модели затухания сигнала, постарался какую-то часть их как раз описать. Хотел бы еще добавить, что еще очень сильно влияет большое количество переотражений сигнала в помещении (чего почти нет на улице). А так же речь идет про смартфоны, то влияет сам человек, который держит телефон в то в левом заднем кармане, то в правом переднем, в руке, у левого/правого уха, что на местоположение сматрфона не влияет, а показания на точках меняться могут кардинально.
Да, вы правы, спасибо! Действительно, у меня же FSPL в формуле в dB считается, поэтому и появился логарифм. А так зависимость, конечно, квадратичная. Сейчас поправлю.
Я думаю, что вы говорите, скорее про EIRP — эффективную изотропную излучаемую мощность, внутри этой формулы как раз есть коэффициент усиления антенны, который определяет, как рассеивается сигнал. Вы конкретно говорите о абсолютном изотропном излучателе.
А FPSL — это уже о затухании конкретной волны в определенном направлении. Собственно формула FSPL явно говорит о логарифмической зависимости.
https://en.wikipedia.org/wiki/Free-space_path_loss
FSPL = 32.4 + (20log10(2,400)) + (20log10(x))
Как я писал, чтобы вычислить конкретный уровень сигнала, нужно рассчитать EIRP ( который содержит коэффициент усиления антенны) и вычесть из него FSPL
Cisco в своей прошлой версии позиционирования (до версии 8.0) использовало две технологии: триангуляцию и Fingerprint. Благодаря этому в частности до восьмой версии включительно был так же доступен механизм калибровки.
В новой версии ( CMX 10) механизм калибровки отсутствует, я спрашивал у консультанта Cisco, ответ был такой, что это потому что технология Fingerprint теперь не используется. К сожалению, документация по 10-й версии пока не такая подробная. Поэтому я пока делаю вывод, что в 10-й версии используется только триангуляция.
Почему отказались от Fingerprint открыто не объясняется. Я подозреваю, либо потому что не сделали ( так как 10-я версия — это полностью новый продукт), либо потому что проявились какие-то тяжелорешаемые проблемы. Мне было бы самому интересно узнать ответ на этот вопрос.
Навес HALO ( модуль и антенна) в GPL стоит около 1000$ и точка должна быть модульная, серия 3ххх, то есть дорогая. При этом для достижения точности 1м требования к покрытию остаются!
Видео занятное, посмотрю и почитаю, спасибо!
У меня сейчас стенд развернут с HALO, я следующей статьёй постараюсь разобраться с ним…
Новые точки доступа комплектуются BLE beacon-ом.
Про это я надеюсь получится рассказать чуть позже в отдельной статье.
time stamps, a channel stamp, signal stamp, and a noise stamp. В анализаторе пакетов эта информация находится в отдельном заголовке, типа Radiotap Header. Если это делает клиентский адаптер, то точка доступа это наверняка может делать и скорее всего делает при необходимости.
Probe request посылается клиентом в самом начале общения с точкой, далее этот тип management фрейма не используется, поэтому замерять уровень сигнала только этих пакетов бесполезно для позиционирования.
Да, это известная проблема, которую я немножко затронул в статье. Во-1, к примеру, точка Cisco (да я думаю большинство) небольшую часть времени тратит на сканирование всех каналов. Можно не попасть на пакет клиента. Поэтому используют дополнительное радио, которое все время занимается только тем, что сканирует каналы, но опять же, приходится перебирать каналы. Чуть проще, когда требуется позиционировать только подключенных клиентов, перебирать каналов приходится в этом случае меньше ( к примеру только 1-6-11 в диапазоне 2.4 ГГц).
Я этот вопрос постараюсь раскрыть в следующей статье, вместе с описанием FastLocation.
Probe request используются только в весьма определенных обстоятельствах, а именно в момент активного сканирования беспроводной среды. В Probe request может быть указан какой-то конкретный SSID, тогда точки с этим SSID возвращают probe response, либо не указан SSID, тогда все точки, что услышали этот запрос, возвращают параметры всех имеющихся SSID.
Что касается iOS9, то полагаю, что это может иметь значение для неассоциированных устройств, тогда действительно будет сложнее отслеживать положения устройств, которые не подключились к беспроводной сети.
У всех телефонов же разные антенны, не уверен, что они передают в служебных пакетах их характеристики (что могло бы немного облегчить расчет).
По поводу того, где держит телефон человек — это действительно очень сильно влияет. Я вот думаю, что в этом случае ситуацию может чуть поправить AoA: данные об углах у нас не должны меняться и клиент теоретически не должен уж сильно «скакать» с места на место при перемещении телефона от левого уха в правый карман.
Для Wi-Fi, в принципе, чтобы отслеживать потоки, не обязательно даже делать CP и заносить данные, можно отслеживать MAC адреса ( для этого клиентам даже не надо подключаться к сети, достаточно отправить пару probe request-ов. К этому можно еще добавить DHCP profiling и HTTP profiling и тоже добавлять к данным о MAC адресе ( тип устройства, тип ОС..)
Согласен про наличии большого числа нюансов в физической модели затухания сигнала, постарался какую-то часть их как раз описать. Хотел бы еще добавить, что еще очень сильно влияет большое количество переотражений сигнала в помещении (чего почти нет на улице). А так же речь идет про смартфоны, то влияет сам человек, который держит телефон в то в левом заднем кармане, то в правом переднем, в руке, у левого/правого уха, что на местоположение сматрфона не влияет, а показания на точках меняться могут кардинально.
А FPSL — это уже о затухании конкретной волны в определенном направлении. Собственно формула FSPL явно говорит о логарифмической зависимости.
https://en.wikipedia.org/wiki/Free-space_path_loss
FSPL = 32.4 + (20log10(2,400)) + (20log10(x))
Как я писал, чтобы вычислить конкретный уровень сигнала, нужно рассчитать EIRP ( который содержит коэффициент усиления антенны) и вычесть из него FSPL