Jump to content
Калькуляторы

бесшовный wi-fi по квартире и на улице (под окнами)

Точки доступа Enterpise уровня, особенно это касается уличных HotSpot поддерживают бесшовный роуминг, а также Fast Transition roaming по стандарту 802.11r. Это например делает Cambium Wi-Fi cnPilot ( пока роуминг второго типа, 802.1r заявлен Q1 2016)- точки доступа корпоративного уровня и HotSpot, это умеет делать, само собой, Cisco и другие продвинутые вендоры вайфай.

Что касается Микротик. Он точно умеет делать роуминг первого типа. Это то, что описывает Saab95. Для домашней и малой корпоративной сети, гостиницы эта схема вполне пригодна. Умеет ли делать Микротик с контроллером Capsman бесшовный роуминг, то есть требуется ли, например, обращение Capsman к серверу Radius при роуминге при EAP Radius аутентификации? Давайте спросим это у Saab95? А вот роуминга 802.11r у Микротика нет.

Что касается UBNT. У него нет бесшовного роуминга второго типа. Первый видимо есть, он есть у всех с фичей min RSSI Threshold. Но вот у убнт есть свой проприетарный ( нестандартный) Fast роуминг третьего типа, называемый Zero Handoff Roaming. Он вроде бы на AP AC пока не работает, поддерживается только старыми точками доступа 802.11n. Он действительно бесшовный и быстрый, но имеет ключевой недостаток. Все точки доступа должны иметь один SSID, Security profile, а главное, должны работать на одной частоте. Тем самым, для плотной high density вайфай сети, где бесшовный роуминг обязателен, UBNT IniFI непригоден. Точки доступа в такой сети на одной частоте будут создавать друг другу помехи. В общем странная у Убнт ситуация получается с роумингом UniFi- там где он нужен, он не работает из за помех, а там где точки доступа не создают друг другу помехи (не слышат друг друга) и роуминг теоретически работает на сетевом уровне L2, но он не нужен, потому что перехода клиента с точки на точку по радио L1 реально нет ;-).

И наконец, оборудование WiFi cnPilot Cambium ( по цене относящийся к лоу кост,например E400 2-х диапазонный 2.4 ГГц 802.11n и 5 Ггц 802.11ac -MSRP199, а по фичам - к премиум сегменту ) умеет ( заявлено в Release 2.0 Q1 2016) делать почти все ( многое), что необходимо корпоративным, indoor и outdoor уличным сетям вайфай публичного доступа, включая роуминг всех рассмотренных выше типов.

Очередные басни теоретика. Камбиум который так нахваливают как хотспот показал себя так себе.В эфире где много точек на одном канале точка частенько входит в ступор, подключения есть а трафик не ходит, лечится ребутом. Если это премиум, то я солист большого театра.

Share this post


Link to post
Share on other sites

Точки доступа Enterpise уровня, особенно это касается уличных HotSpot поддерживают бесшовный роуминг, а также Fast Transition roaming по стандарту 802.11r. Это например делает Cambium Wi-Fi cnPilot ( пока роуминг второго типа, 802.1r заявлен Q1 2016)- точки доступа корпоративного уровня и HotSpot, это умеет делать, само собой, Cisco и другие продвинутые вендоры вайфай.

Что касается Микротик. Он точно умеет делать роуминг первого типа. Это то, что описывает Saab95. Для домашней и малой корпоративной сети, гостиницы эта схема вполне пригодна. Умеет ли делать Микротик с контроллером Capsman бесшовный роуминг, то есть требуется ли, например, обращение Capsman к серверу Radius при роуминге при EAP Radius аутентификации? Давайте спросим это у Saab95? А вот роуминга 802.11r у Микротика нет.

Что касается UBNT. У него нет бесшовного роуминга второго типа. Первый видимо есть, он есть у всех с фичей min RSSI Threshold. Но вот у убнт есть свой проприетарный ( нестандартный) Fast роуминг третьего типа, называемый Zero Handoff Roaming. Он вроде бы на AP AC пока не работает, поддерживается только старыми точками доступа 802.11n. Он действительно бесшовный и быстрый, но имеет ключевой недостаток. Все точки доступа должны иметь один SSID, Security profile, а главное, должны работать на одной частоте. Тем самым, для плотной high density вайфай сети, где бесшовный роуминг обязателен, UBNT IniFI непригоден. Точки доступа в такой сети на одной частоте будут создавать друг другу помехи. В общем странная у Убнт ситуация получается с роумингом UniFi- там где он нужен, он не работает из за помех, а там где точки доступа не создают друг другу помехи (не слышат друг друга) и роуминг теоретически работает на сетевом уровне L2, но он не нужен, потому что перехода клиента с точки на точку по радио L1 реально нет ;-).

И наконец, оборудование WiFi cnPilot Cambium ( по цене относящийся к лоу кост,например E400 2-х диапазонный 2.4 ГГц 802.11n и 5 Ггц 802.11ac -MSRP199, а по фичам - к премиум сегменту ) умеет ( заявлено в Release 2.0 Q1 2016) делать почти все ( многое), что необходимо корпоративным, indoor и outdoor уличным сетям вайфай публичного доступа, включая роуминг всех рассмотренных выше типов.

Очередные басни теоретика. Камбиум который так нахваливают как хотспот показал себя так себе.В эфире где много точек на одном канале точка частенько входит в ступор, подключения есть а трафик не ходит, лечится ребутом. Если это премиум, то я солист большого театра.

Может и случался ступор, подтверждаю, бывало дело, но софт HotSpot же был в самом первом релизе 1.0. На прошлой неделе вышла прошивка HotSpot 1.6, , жалоб пока не получаем. А премиум сегмент определяется фичами софта ,в данном случае необходимыми для масштабируемых сетей Indoor/Outdoor HotSpot.

Share this post


Link to post
Share on other sites

Точки доступа Enterpise уровня, особенно это касается уличных HotSpot поддерживают бесшовный роуминг, а также Fast Transition roaming по стандарту 802.11r. Это например делает Cambium Wi-Fi cnPilot ( пока роуминг второго типа, 802.1r заявлен Q1 2016)- точки доступа корпоративного уровня и HotSpot, это умеет делать, само собой, Cisco и другие продвинутые вендоры вайфай.

Что касается Микротик. Он точно умеет делать роуминг первого типа. Это то, что описывает Saab95. Для домашней и малой корпоративной сети, гостиницы эта схема вполне пригодна. Умеет ли делать Микротик с контроллером Capsman бесшовный роуминг, то есть требуется ли, например, обращение Capsman к серверу Radius при роуминге при EAP Radius аутентификации? Давайте спросим это у Saab95? А вот роуминга 802.11r у Микротика нет.

Что касается UBNT. У него нет бесшовного роуминга второго типа. Первый видимо есть, он есть у всех с фичей min RSSI Threshold. Но вот у убнт есть свой проприетарный ( нестандартный) Fast роуминг третьего типа, называемый Zero Handoff Roaming. Он вроде бы на AP AC пока не работает, поддерживается только старыми точками доступа 802.11n. Он действительно бесшовный и быстрый, но имеет ключевой недостаток. Все точки доступа должны иметь один SSID, Security profile, а главное, должны работать на одной частоте. Тем самым, для плотной high density вайфай сети, где бесшовный роуминг обязателен, UBNT IniFI непригоден. Точки доступа в такой сети на одной частоте будут создавать друг другу помехи. В общем странная у Убнт ситуация получается с роумингом UniFi- там где он нужен, он не работает из за помех, а там где точки доступа не создают друг другу помехи (не слышат друг друга) и роуминг теоретически работает на сетевом уровне L2, но он не нужен, потому что перехода клиента с точки на точку по радио L1 реально нет ;-).

И наконец, оборудование WiFi cnPilot Cambium ( по цене относящийся к лоу кост,например E400 2-х диапазонный 2.4 ГГц 802.11n и 5 Ггц 802.11ac -MSRP199, а по фичам - к премиум сегменту ) умеет ( заявлено в Release 2.0 Q1 2016) делать почти все ( многое), что необходимо корпоративным, indoor и outdoor уличным сетям вайфай публичного доступа, включая роуминг всех рассмотренных выше типов.

Очередные басни теоретика. Камбиум который так нахваливают как хотспот показал себя так себе.В эфире где много точек на одном канале точка частенько входит в ступор, подключения есть а трафик не ходит, лечится ребутом. Если это премиум, то я солист большого театра.

Может и случался ступор, подтверждаю, бывало дело, но софт HotSpot же был в самом первом релизе 1.0. На прошлой неделе вышла прошивка HotSpot 1.6, , жалоб пока не получаем. А премиум сегмент определяется фичами софта ,в данном случае необходимыми для масштабируемых сетей Indoor/Outdoor HotSpot.

Мдэ ... если девайс зависает, то фичи ничего не решают.

Share this post


Link to post
Share on other sites

Точки доступа Enterpise уровня, особенно это касается уличных HotSpot поддерживают бесшовный роуминг, а также Fast Transition roaming по стандарту 802.11r. Это например делает Cambium Wi-Fi cnPilot ( пока роуминг второго типа, 802.1r заявлен Q1 2016)- точки доступа корпоративного уровня и HotSpot, это умеет делать, само собой, Cisco и другие продвинутые вендоры вайфай.

Что касается Микротик. Он точно умеет делать роуминг первого типа. Это то, что описывает Saab95. Для домашней и малой корпоративной сети, гостиницы эта схема вполне пригодна. Умеет ли делать Микротик с контроллером Capsman бесшовный роуминг, то есть требуется ли, например, обращение Capsman к серверу Radius при роуминге при EAP Radius аутентификации? Давайте спросим это у Saab95? А вот роуминга 802.11r у Микротика нет.

Что касается UBNT. У него нет бесшовного роуминга второго типа. Первый видимо есть, он есть у всех с фичей min RSSI Threshold. Но вот у убнт есть свой проприетарный ( нестандартный) Fast роуминг третьего типа, называемый Zero Handoff Roaming. Он вроде бы на AP AC пока не работает, поддерживается только старыми точками доступа 802.11n. Он действительно бесшовный и быстрый, но имеет ключевой недостаток. Все точки доступа должны иметь один SSID, Security profile, а главное, должны работать на одной частоте. Тем самым, для плотной high density вайфай сети, где бесшовный роуминг обязателен, UBNT IniFI непригоден. Точки доступа в такой сети на одной частоте будут создавать друг другу помехи. В общем странная у Убнт ситуация получается с роумингом UniFi- там где он нужен, он не работает из за помех, а там где точки доступа не создают друг другу помехи (не слышат друг друга) и роуминг теоретически работает на сетевом уровне L2, но он не нужен, потому что перехода клиента с точки на точку по радио L1 реально нет ;-).

И наконец, оборудование WiFi cnPilot Cambium ( по цене относящийся к лоу кост,например E400 2-х диапазонный 2.4 ГГц 802.11n и 5 Ггц 802.11ac -MSRP199, а по фичам - к премиум сегменту ) умеет ( заявлено в Release 2.0 Q1 2016) делать почти все ( многое), что необходимо корпоративным, indoor и outdoor уличным сетям вайфай публичного доступа, включая роуминг всех рассмотренных выше типов.

Очередные басни теоретика. Камбиум который так нахваливают как хотспот показал себя так себе.В эфире где много точек на одном канале точка частенько входит в ступор, подключения есть а трафик не ходит, лечится ребутом. Если это премиум, то я солист большого театра.

Может и случался ступор, подтверждаю, бывало дело, но софт HotSpot же был в самом первом релизе 1.0. На прошлой неделе вышла прошивка HotSpot 1.6, , жалоб пока не получаем. А премиум сегмент определяется фичами софта ,в данном случае необходимыми для масштабируемых сетей Indoor/Outdoor HotSpot.

Мдэ ... если девайс зависает, то фичи ничего не решают.

Здесь мы в теме говорим о фиче роуминга, а зависает она (или что то другое ) у какого то оборудования или нет, это другой вопрос.

Share this post


Link to post
Share on other sites

Славик изобрел хэндовер, лол.

Ubnt unifi может работать с клиентом с нулевым временем переключения только при правильном радиопланировании, и разработчики не скрывают этого.

Контроллерные решения реализуют жесткий хэндовер, brake-before-make, для бардака из 802.11 это абсолютно нормально, sfstudio предельно четко на форуме это расписал.

Make-before-brake в 802.11 уже невозможен, из соображений обратной совместимости. И это фигово.

 

Да, до особо одаренных: Убики не делают make-before-brakе

Share this post


Link to post
Share on other sites

Здесь мы в теме говорим о фиче роуминга, а зависает она (или что то другое ) у какого то оборудования или нет, это другой вопрос.

 

Рассматривать по отдельности функционал оборудования и само оборудование бессмысленно. Пусть в нем будет самый ***тый роуминг, толку от него ноль если само устройство виснет. Пока видна очередная твоя попытка впарить "сырое" оборудование которое допилят в процессе.

Share this post


Link to post
Share on other sites

Нет метода - нет укора, всё верно ЧО =). Всё что может ваш микротик - выпнуть клиента. Всё остальное зависит исключительно от клиента, в т.ч. метод переключения (с/без рескана, с дропом всех соединений или без и т.д.). Я вам это уже расписывал, но вы продолжаете вешать лапшу на уши людям.

 

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

Метод, который использует микротик, самый оптимальный по затратам, при этом умеет его он из коробки.

Ваше же решение, насколько я понял, из коробки это не умеет и нужна специальная прошивка. Как настроить это дело на микротике расписано в интернете, как сделать аналог на ваших устройствах, нигде на просторах интернета не обозначено.

 

Для того что бы решить эти проблемы были придуманы доп расширения для 802.11 (K/R/V) которые ваш микротик не умеет. ZH был придуман что бы обойти проблему с тем что клиенты зачастую тоже нифига не умеют, и оно даже как-то работает, но есть ограничения (какие - тоже буквально недавно на пальцах расписывал).

 

Эти проблемы придумывают производители дорогих контроллерных решений, иначе их никто и покупать не будет. Вон посмотрите на современный автопром и то, что вокруг него крутится - на центральных каналах в передачах автомобильной тематики люди с умным видом предлагают добавки в масло, которые, по их словам, ресурс увеличивают и ремонт откладывают. Люди ведутся на это и покупают. Хотя на практике лей не лей, если есть износ, никуда он не денется.

 

P.S. Антон, хватит уже. Я вот лично наверное попрошу администрацию отправить вас в бессрочное RO ибо даже для продажников такое беззастенчивое враньё недопустимо. Простите, откровенно надоела ваша бредятина в каждой теме.

 

 

Ну если у вас нет возможности конвертить мультикаст в уникаст на микротике да, придётся вам гонять напрямую.

 

У нас уже юникаст потоки, конвертить ничего не надо.

 

Расскажите это ТТК к примеру. Хотя да, ваш пионэрнет действительно более правильный оператор. Более того, мультикаст тут вообще сбоку, учитывая что на отрезке AP->клиент должна быть выполнена конверсия мультикаста в уникаст, т.е. либо банальный m2u с подменой dstip в зависимости от подписки, либо вообще конвертация в http stream (но как бы не того не того ваш микротик осилить не в силах).

 

У ТТК есть пакеты юникаста.

 

получение нового IP адреса через DHCP

 

Обычно при работе в L2 сети получение нового IP адреса не требуется, поэтому переключение происходит быстро.

 

обращение Capsman к серверу Radius при роуминге при EAP Radius аутентификации?

 

Авторизация по радиусу, если использовать средства микротика, происходит быстро, во всяком случае меньше, чем 500мс, более того, если клиент делает попытки подключения к нескольким точкам сразу, можно понять какую он лучше слышит и пустить на нужную.

 

Ubnt unifi может работать с клиентом с нулевым временем переключения только при правильном радиопланировании, и разработчики не скрывают этого.

 

Ничего он не работает и не может, постоянно есть желающие построить себе сеть на юбиках в бизнес центрах, потом спрашивают можно ли вернуть оборудование обратно.

Share this post


Link to post
Share on other sites

Точки доступа Enterpise уровня, особенно это касается уличных HotSpot поддерживают бесшовный роуминг, а также Fast Transition roaming по стандарту 802.11r.

 

Всё что описывает FastTransition так это миграцию без полной фазы реаутентификации в шифрованных сетях, больше оно ничего не описывает. Плюс требуется поддержка со стороны клиента. Я потратил уйму времени на разбор всех этих расширений 802.11 и вывод такой - оно скорее мертво http://forum.nag.ru/forum/index.php?showtopic=108990&view=findpost&p=1194503. А гордое слово ынтырпрайз уже ругательным давно стало.

 

Что касается Микротик. Он точно умеет делать роуминг первого типа.

 

Баскетбол это не когда тупо кидают мяч, а когда все участники играют по правилам. В данном случае это не роуминг, а скидывание клиента с АП в надежде что он реконнектиться к другой AP с более высоким уровнем. Причём чистая рулетка ибо всё зависит от правил выдуманных производителем клиента, а не АП. Роумингом это можно назвать с ооооооооооооооооооочень большой натяжкой. Та же схема реализована у меня в Wive, в разы гибче чем у микротика, но всё равно это не роуминг.

 

Что такое роуминг посмотрите в GSM там на уровне протокола база может сказать клиенту на какую базу мигрировать не смотря на то что уровень от неё может быть ниже, но т.к. ближайшая база с высоким уровнем уже выбрала свой лимит по таймслотам на неё перемещать клиента уже нельзя и этого не произойдёт.

 

Причём всё это чётко стандартизовано и поддерживается даже 10 баксовыми телефонами. Т.е. это часть СТАНДАРТА.

 

Микротик даже qload в beacon не отдаёт (в отличии от wive например), т.е. клиент даже если бы умел бы получать доп инфу и использовать её при роуминге не сможет этого сделать.

 

Это то, что описывает Saab95. Для домашней и малой корпоративной сети, гостиницы эта схема вполне пригодна. Умеет ли делать Микротик с контроллером Capsman бесшовный роуминг, то есть требуется ли, например, обращение Capsman к серверу Radius при роуминге при EAP Radius аутентификации? Давайте спросим это у Saab95? А вот роуминга 802.11r у Микротика нет.

 

Смешались в кучу кони-люди. Preauth эт нифига не роуминг опять же. А схема с выпиныванием клиента действительно пригодна во многих случаях хотя и несёт массу потенциальных проблем. Но весь вопрос в том что называть это поддержкой роуминга - лукавство.

 

Что касается UBNT. У него нет бесшовного роуминга второго типа. Первый видимо есть, он есть у всех с фичей min RSSI Threshold.

 

Preauth ? Да вот всяко есть ибо штатная функция hostapd который у них и 802.11r реализует к примеру.

 

Но вот у убнт есть свой проприетарный ( нестандартный) Fast роуминг третьего типа, называемый Zero Handoff Roaming. Он вроде бы на AP AC пока не работает, поддерживается только старыми точками доступа 802.11n. Он действительно бесшовный и быстрый, но имеет ключевой недостаток.

 

И этот недостаток совсем не в том что вы так усиленно расписываете. Я расписывал на пальцах как работает ZH и какой у него ключевой недостаток в соседней теме http://forum.nag.ru/forum/index.php?showtopic=111219&view=findpost&p=1212388.

 

Нет никаких роумингов первого второго и третьего типа. Всё что есть в 802.11 это ZH (и его вариации, причём это нестандартный костыль), тупое вышибание клиента по RSSI, ну и варианты как ускорить реаутентификацию (802.1x preauth/802.11r).

 

На слово роуминг с натяжкой подходит только ZH. Всё остальное это рулетка т.к. требуется поддержка от клиентов которой часто нет, или просто перекладывание решение на сторону клиента с вариациями (тупо как у микротика скинуть и скрестить пальцы, или более гибко как у меня с возможностью не пустить и/или проигнорировать запросы от клиента в определённых ситуациях http://forum.nag.ru/forum/index.php?showtopic=108990&view=findpost&p=1182990 с realtime или отложенным принятием решения об отстреле).

Share this post


Link to post
Share on other sites

Славик изобрел хэндовер, лол.

Ubnt unifi может работать с клиентом с нулевым временем переключения только при правильном радиопланировании, и разработчики не скрывают этого.

Контроллерные решения реализуют жесткий хэндовер, brake-before-make, для бардака из 802.11 это абсолютно нормально, sfstudio предельно четко на форуме это расписал.

Make-before-brake в 802.11 уже невозможен, из соображений обратной совместимости. И это фигово.

 

 

Мне сказали что 802.11r не достаточно, так как мы хотим развертит безшовный роуминг в офисе. Типо все сотрудники сможет ходит и говорит с клиентами черех Skype/Line/whatsup. Тут надо чтоб была поддержка тоже 802.11k.

так тепер ищем оборудование которое поддержик все это. Сперва тестировали UBNT так как у них технология другая, но типо должно работать безшовный роуминг.

Но при тестирование появилис проблемы когда просто не переключалис на другую ТД, а оставас подключение к первому ТД и свях терялас.

Сейчас смотрим кого еще брать. Сиско дорого.

Share this post


Link to post
Share on other sites

Вы сначала клиентов найдите которые K+R умеют. Если клиенты не умеют то хоть золотые точки поставь. Костыль вида ZH кстати вам может вполне помочь. Как раз из плюсов что клиенты могут вообще ничего не уметь. Минус ёмкость сети клиентов 20-30 (независимо от числа АП), дальше это будет уже ад (почему - расписывал, см пост выше).

Share this post


Link to post
Share on other sites

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

 

Опять всё в кучу.

 

Метод, который использует микротик, самый оптимальный по затратам, при этом умеет его он из коробки.

 

Это не метод это увы костыль. Ещё более куций чем у нас.

 

Ваше же решение, насколько я понял, из коробки это не умеет и нужна специальная прошивка.ъ

 

Глаза разуйте. Оно с завода идёт с этой фичей месяца как 4ре, остальные штатно обновляются и фича лёгким движением руки появляется.

 

Как настроить это дело на микротике расписано в интернете, как сделать аналог на ваших устройствах, нигде на просторах интернета не обозначено.

 

Опять враньё, зайдите в соответствующий раздел + вас прекрасно проконсультируют как по мылу support@nag.ru/wifi@nag.ru так и по телефону/шкайпу.

 

Эти проблемы придумывают производители дорогих контроллерных решений, иначе их никто и покупать не будет. Вон посмотрите на современный автопром и то, что вокруг него крутится - на центральных каналах в передачах автомобильной тематики люди с умным видом предлагают добавки в масло, которые, по их словам, ресурс увеличивают и ремонт откладывают. Люди ведутся на это и покупают. Хотя на практике лей не лей, если есть износ, никуда он не денется.

 

Это реальные проблемы появившиеся из-за подхода wifi альянса к сертификации. Был бы 802.11 стандартом где все фичи обязательны к исполнению (как тот же GSM) не было бы проблем. А с 802.11 имеем кучу чипов и ниодного полноценного, каждый что-то из набора фич описанных "стандартом" не умеют.

 

У нас уже юникаст потоки, конвертить ничего не надо.

У ТТК есть пакеты юникаста.

 

Ваша пионерия слабо интересно, вы можете и кастрюльки вешать продолжать, и на мокротики молиться.

 

Не каждый псих будет при сотнях тысяч юзверей гонять поток ТВ отдельно для каждого, а с приходом 4K TV возможность не дублировать потоки для каждого юзверя будет ещё критичнее. То что у ТТК на сайте аля онлайн ТВ это жуткое позорное пережатое непонятно что. Нормальное ТВ у них идёт мультикастом штатно. У меня даже фиды в xupnpd из коробки для них забиты т.к. ставят наше железо.

 

Обычно при работе в L2 сети получение нового IP адреса не требуется, поэтому переключение происходит быстро.

 

Если клиент не решит что надо всё с нуля переспросить при link down/up, а часто это именно так, дроп адреса->дроп стэйтов->перезапрос адреса с потерей всех соединений. Из 2х десятков доступных мне планшетов не дропает стэйты и не перезапрашивает адрес полностью только старенький самс.

Share this post


Link to post
Share on other sites

Мне сказали что 802.11r не достаточно, так как мы хотим развертит безшовный роуминг в офисе. Типо все сотрудники сможет ходит и говорит с клиентами черех Skype/Line/whatsup. Тут надо чтоб была поддержка тоже 802.11k.

так тепер ищем оборудование которое поддержик все это. Сперва тестировали UBNT так как у них технология другая, но типо должно работать безшовный роуминг.

Но при тестирование появилис проблемы когда просто не переключалис на другую ТД, а оставас подключение к первому ТД и свях терялас.

Сейчас смотрим кого еще брать. Сиско дорого.

ZH ubnt требует очень вдумчивого радиопланирования. 802.11r есть далее не везде. Если у вас суперкрутая организация, то, возможно, вам навстречу пойдут сотовые операторы, развернув у вас indoor базовую станцию. В сложившейся ситуации только umts/lte обеспечит нужный уровень сервиса.

Share this post


Link to post
Share on other sites

Глаза разуйте. Оно с завода идёт с этой фичей месяца как 4ре, остальные штатно обновляются и фича лёгким движением руки появляется.

 

У микротика эта фича уже с десяток лет идет штатно и обновляться не нужно.

 

Опять враньё, зайдите в соответствующий раздел + вас прекрасно проконсультируют как по мылу support@nag.ru/wifi@nag.ru так и по телефону/шкайпу.

 

Это если покупать не одну коробку железок, каждого, кто захочет купить один роутер никто консультировать не будет.

 

Не каждый псих будет при сотнях тысяч юзверей гонять поток ТВ отдельно для каждого, а с приходом 4K TV возможность не дублировать потоки для каждого юзверя будет ещё критичнее. То что у ТТК на сайте аля онлайн ТВ это жуткое позорное пережатое непонятно что. Нормальное ТВ у них идёт мультикастом штатно. У меня даже фиды в xupnpd из коробки для них забиты т.к. ставят наше железо.

 

Есть различные методы решения, в том числе юникаст роутинг, если многие абоненты смотрят один и тот же канал.

 

Если клиент не решит что надо всё с нуля переспросить при link down/up, а часто это именно так, дроп адреса->дроп стэйтов->перезапрос адреса с потерей всех соединений. Из 2х десятков доступных мне планшетов не дропает стэйты и не перезапрашивает адрес полностью только старенький самс.

 

Не замечал такого поведения при переключения устройств на микротиках.

Share this post


Link to post
Share on other sites

ZH ubnt требует очень вдумчивого радиопланирования.

Должно быть сделано так, чтобы 1) точки доступа , находясь на одной частоте,не слышали друг друга и 2) клиент, переходя из одной точки доступа к другой слышал в момент перехода обе точки доступа. Можно такое сделать в офисе? Да, исходя из конфигурации помещений и коридоров, но геморно, чаще трудно или невозможно. А вот на улице таких условий на открытом пространстве создать точно невозможно. Outdoor точки доступа, оснащенные антенной 6-9 Дби на одной частоте всегда будут лучше слышать друг друга ( и мешать друг другу ) , чем своих клиентов. Поэтому ZH роуминг ubnt- очередная бесмысленная, бесполезная и неработающая на практике фича от UBNT.

Если нужен FT roaming c временем переключения <40 для для работы VoIP, то нужно оборудование ( точки доступа и обязательно контроллер) с поддержкой IEEE стандарта 802.11r ( ныне обязательная фича для FT) . Клиенты для FT роуминга также обязательно должны должны поддерживать 802.11r , Android и iOS это поодерживают. Все остальные способы FT roaming типа OKC, pre-authetication, Cisco CCKM, ZH ubnt - это все пропритарные фичи, которые можно использовать в корпоративных сетях, но если речь идет о публичных сетях HotSpot, то нет.

Следует отметить что тип роуминга определяется механизмом аутентификации клиента.

Ключевой механизм FT роуминга - решение о автоматической реаутентификации клиента пр роуминге клиента принимается точкой доступа по информации о клиенте, полученной от контроллера.

Если нужен не FT , а обычный seamless роуминг, когда решение о автоматической реаутентификации клиента принимается контролером доступа (c временем переключения в среднем 500 мс) по информации о клиенте, полученной от Radius сервера(в случае EAP аутентификации), то необходимо оборудование ( точка доступа и контролер) с поддержкой стандартной атентификации WPA Enterprise ( а точнее WPA-PSK, PEAP MSCHAPv2)и на точке доступа и на контроллере. Ни ubnt, ни МТ ( в режиме HotSpot) этого не умеют. И клиентские Android и iOS также поддерживают WPA/WPA2 и EAP для аутентификации на Radius.

Share this post


Link to post
Share on other sites

У микротика эта фича уже с десяток лет идет штатно и обновляться не нужно.

 

У микротика это не фича, а огрызок. Чем отличается я вам уже показывал.

 

Это если покупать не одну коробку железок, каждого, кто захочет купить один роутер никто консультировать не будет.

 

Я не в курсе кто кого купил, однако вполне отвечаю на форуме, и насколько мне известно на тикеты так же отвечают независимо от того сколько куплено. Так что ХВАТИТ ВРАТЬ.

 

Есть различные методы решения, в том числе юникаст роутинг, если многие абоненты смотрят один и тот же канал.

 

Чего? Т.е. а просто у вас уникаст не роутиться? Или что вы под уникаст роутингом подразумеваете? Линки! Пруфы!

 

Не замечал такого поведения при переключения устройств на микротиках.

 

Потому что выборка поди из 1,5 яблок.

Share this post


Link to post
Share on other sites

Должно быть сделано так

 

Прочитав сей опус вы тупо не въезжаете как работает костыль под ZH.

 

Я вам поясню (хотя уже пояснял). По сути логика пилиться на несколько частей:

1) фронтэнды - это AP в режиме тупо что подали в хвост то передали, что прилетело с эфира то и приняли

2) бэкэнд - это контроллер/сервер (назовите как угодно), который набивает и выгребает очереди с AP, он же принимает решение с какой АП отправить клиенту пакет

 

Дык вот, клиент вообще не в курсе что там не одна АП (и это не как наш местный клоун на букву С утверждает, т.е. не навешивание одинаковых SSID/BSSID, это именно что распределённая AP). Всё рулиться уровне RX/TX очередей (примерно как в MU-MIMO между каналами, только другую проблему решает, а так тоже независимые очереди). Проблема в том что это не увеличивает ёмкости сети. Т.е. вся сеть будет такой же ёмкостью как и одна отдельно взятая АП, т.к. время вещание лимитирована. Это просто разнос приёма передачи на физ уровне разными модулями. Т.е. по сути одна разодранная по разным точкам АП. Так же работал аналог у Мираки.

 

Из плюсов - клиент может не знать ничего о роуминге и всё будет работать и полностью прозрачно, из минусов малая ёмкость и отсутствие масштабируемости по числу клиентов. Т.е. весьма узкоспециализированное решение.

 

И да, точки как раз друг другу при таком раскладе мешать не будут, ибо TX очередь для отправки выбирается с привязкой к той физ АП с которой прилетел "самый громкий" фрэйм с этого клиента за последние N отсчётов времени.

Share this post


Link to post
Share on other sites

Если нужен не FT , а обычный seamless роуминг, когда решение о автоматической реаутентификации клиента принимается контролером доступа (c временем переключения в среднем 500 мс) по информации о клиенте, полученной от Radius сервера(в случае EAP аутентификации), то необходимо оборудование ( точка доступа и контролер) с поддержкой стандартной атентификации WPA Enterprise ( а точнее WPA-PSK, PEAP MSCHAPv2)и на точке доступа и на контроллере. Ни ubnt, ни МТ ( в режиме HotSpot) этого не умеют. И клиентские Android и iOS также поддерживают WPA/WPA2 и EAP для аутентификации на Radius.

 

Так работает preauth и требует ессно 802.1x а PEAP или не PEAP дело 99е. И к "обычному" бесшовному роумингу это так же не имеет отношения.

Share this post


Link to post
Share on other sites

Сякунду, zh работает без контроллера. Все АР должны быть в одном броадкаст домене, с вещанием они самостоятельно разбираются. По крайней мере, один раз мы его ставили, и контроллер прилег надолго по питанию, на работу АР это никак не повлияло.

Share this post


Link to post
Share on other sites

Что-то вы путаете, ZH именно что требовал контроллера. Может конечно нарулили что одна из AP берёт на себя функцию тасовки пакетов по очередям.

Share this post


Link to post
Share on other sites

Должно быть сделано так

 

Прочитав сей опус вы тупо не въезжаете как работает костыль под ZH.

 

Я вам поясню (хотя уже пояснял). По сути логика пилиться на несколько частей:

1) фронтэнды - это AP в режиме тупо что подали в хвост то передали, что прилетело с эфира то и приняли

2) бэкэнд - это контроллер/сервер (назовите как угодно), который набивает и выгребает очереди с AP, он же принимает решение с какой АП отправить клиенту пакет

 

Дык вот, клиент вообще не в курсе что там не одна АП (и это не как наш местный клоун на букву С утверждает, т.е. не навешивание одинаковых SSID/BSSID, это именно что распределённая AP). Всё рулиться уровне RX/TX очередей (примерно как в MU-MIMO между каналами, только другую проблему решает, а так тоже независимые очереди). Проблема в том что это не увеличивает ёмкости сети. Т.е. вся сеть будет такой же ёмкостью как и одна отдельно взятая АП, т.к. время вещание лимитирована. Это просто разнос приёма передачи на физ уровне разными модулями. Т.е. по сути одна разодранная по разным точкам АП. Так же работал аналог у Мираки.

 

Из плюсов - клиент может не знать ничего о роуминге и всё будет работать и полностью прозрачно, из минусов малая ёмкость и отсутствие масштабируемости по числу клиентов. Т.е. весьма узкоспециализированное решение.

 

И да, точки как раз друг другу при таком раскладе мешать не будут, ибо TX очередь для отправки выбирается с привязкой к той физ АП с которой прилетел "самый громкий" фрэйм с этого клиента за последние N отсчётов времени.

То что вы описали вообще не имеет никакого отношения к роумингу между AP. Это что то вроде проприетарного распределения нагрузки между AP или х.з. что. Роуминг клиента,- вообще любой 1) между Radius серверами провайдеров WISPr, 2)между AP одного или нескольких контролеров в группе seamless или FT roaming - это вопрос механизма аутентификации клиента при смене точки доступа- а именно- где и как аутентифицируется клиент при смене точки доступа.Вопрос передачи управления трафиком клиента -вторичен. Никакие фронэнды и бекэнды, очереди пакетов не имеют к аутентификации клиента при смене точки доступа -роуминге никакого отношения. Мы вообще говорим о разных вещах.

Share this post


Link to post
Share on other sites

Хорошо. Чётко и громко определение seamless rouming! Особенно в ключе открытой сети.

Share this post


Link to post
Share on other sites

Это прописано в фичелисте контроллера третьей версии (речь про необходимость контроллера)

Share this post


Link to post
Share on other sites

Сякунду, zh работает без контроллера. Все АР должны быть в одном броадкаст домене, с вещанием они самостоятельно разбираются. По крайней мере, один раз мы его ставили, и контроллер прилег надолго по питанию, на работу АР это никак не повлияло.

При FT ( Fast Transition) роуминге решение об аутенфикации клиента принимает AP. Один раз клиент подключился к любому AP в группу под управлением одного контролера и все,далее этот AP передает ключи доступа этого клиента своему контроллеру , а тот их потом пересылает( в случае ZH ubnt -малтикастом в L2 сети) всем остальным AP в группе. Дальше контроллер можно вырубить, и все равно этот клиент будет свободно перемещаться между всеми AP в группе c FT роумингом ( без повторной аутентификации) в течении некоторого времени жизни ключей- длительности хранения ключей доступа клиента в кеши всех точек доступа.

Zero Handoff ubnt - это один из проприетарных ( нестандартных) видов аутентификации , по способу реализации схожем с стандартными методами Fast Transition роуминг. Поскольку все AP при ZH должны работать на одной частоте, то зоны действия точек доступа AP ubnt не должны перекрываться, поэтому при ZH обычно происходит физический дисконнект клиента от одной AP и подключение к другой AP, но при этом повторная аутентфикация, но новой точке доступа не происходит, потому что новый AP уже заранее знает, что клиент "свой" ( то есть происходит реаутентификация по упрощенной процедуре). При стандартном FT например 802.11r клиент отключается от старой AP после реаутентификации на новой AP ( если зоны этих AP перекрываются). Но если зоны не перекрываются, то FT роуминг все равно работает,то есть не требуется повторная аутентификация, но с возможной потерей коннекта с AP по радио при смене AP.

Share this post


Link to post
Share on other sites

Ещё раз ZH это не вид аутентификации, и работает на открытой сети. Как минимум по данным от них. Это именно реализация разнесённой AP. Более того что бы клиент смог перемещаться без реаутентификации мало что бы AP это умела, это должен уметь и клиент. Хоть проприретарный там протокол хоть открытый. Клиент должен уметь корректно реагировать на перемещение (для клиента любое перемещение это link down/up уровнем выше или ниже не важно).

 

P.S. Задержка связанная с реаутентификацией не единственная и не главная проблема.

Share this post


Link to post
Share on other sites

Хорошо. Чётко и громко определение seamless rouming! Особенно в ключе открытой сети.

Определение Cisco

Mobility, or roaming, is a wireless LAN client’s ability to maintain its association seamlessly from one access point to another securely and with as little latency as possible.

При этом seamless- понятие относительное по отношению к сервису ( работающему приложению), он не должен прерываться ( деградировать) и определяется обеспечиваем latency ( или transition time) при смене AP. Для разных сервисов требуемый Transition time разный, например для VoIP он должен быть <40мс, для видео < 1c ( или типа того, зависит от потока). При этом seamless не означает обязательность обеспечения seamless ( без прерываний ) коннекта клиента с AP на физическом (радио) уровне типа make before break.

И Securely - это и есть защишенная ( с шифрованием трафика) аутентифкация клиента.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this