`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

802.11ac Wave2 Wi-Fi – не спешим (ч4) – MU-MIMO

В трех предыдущих частях мы рассмотрели обещания, потоки и каналы 802.11ac Wave2. Сегодня закрываем тему последним, самым важным, нововведением – Multi-User MIMO.

Напомним, в Wi-Fi предыдущего поколения была проблемка: связь была полудуплексная. А, следовательно, если с точкой 4x4:4@160MHz (потенциально большая пропускная способность) общается клиент 1x1:1@20Mhz, то вся остальная часть «трубы» простаивает. А в данном случае это 1- 20/(4*160) ~= 97% !

802.11ac Wave2 Wi-Fi – не спешим (ч4) – MU-MIMO

[Здесь и далее иллюстрации из White Paper от Xirrus - по поводу MU-MIMO писали вообще все, но если бумаги от Cisco и Aruba техничны донельзя, а другие – маркетинговы донельзя, то эта – хороший пример сбалансированной подачи. Молодцы.].

Сделать связь полнодуплексной без переделки ВСЕГО-ВСЕГО не получится, но ситуацию можно улучшить: у наших коллег из «большой» сотовой связи тоже всё как-бы не совсем полнодуплексно, но одна сота обслуживает множество клиентов на огромной территории.

И тут начинаются нюансы... Напомним, и в современном Wi-Fi и в современной большой сотовой связи используется OFDM, в котором канал делится на большое количество (десятки) поднесущих. По сути, скажем, 20MHz канала делятся на 50 канальчиков в 0.4 MHz. На самом деле все сложнее, но для нашего примера сойдет. Далее оказывается, что с современными скоростями клиенту не нужны все 20Mhz – ему достаточно всего несколько «подканалов» (в зависимости от типа клиента и его задач). Есть механизм посредством которого клиент и базовая станция договариваются, какие подканалы брать и как долго их использовать. В общем, всё классно. Так работают Wi-MAX, LTE и иже с ними.

Проблема лишь в том, как это запихнуть в точку доступа? Базовая станция LTE – не крохотная коробочка, висящая под потолком, и питается не по PoE. Поэтому всей это красоты в 802.11ac мы не увидим (хотя, возможно, увидим в 802.11ax году эдак в 2019). А вместо этого увидим вот что.

Еще в 802.11ac Wave 1 сделали обязательным Beamforming (динамическое управление диаграммой направленности антенны). В Wave2 сказали: «А давайте-ка использовать Beamforming, чтобы слать сразу несколько потоков РАЗНЫМ клиентам?»

802.11ac Wave2 Wi-Fi – не спешим (ч4) – MU-MIMO

Ну а что – звучит неплохо! Теперь если на точке 4x4:4 сидят клиенты 1x1, то можно работать сразу с четырьмя. А это как бы в четыре раза быстрее! Кроме того, если есть клиенты с 2SS и 3SS – их тоже можно комбинировать: 1+1+2, 1+3, 2+2. Таким образом, задействован весь скоростной потенциал точки – ничего (из оплаченного) не простаивает – классно!

Давайте разбираться.

Первое. Обратите внимание, что везде говорится только о передаче от точки к клиенту. Обратили? А где говорится о передаче от клиента к точке? Верно – там всё по-старому, и пока клиент 1x1:1@20 передает – все остальные молчат. На самом деле, это не так и плохо, так как клиенты скачивают гораздо больше, чем закачивают. А служебные пакеты (типа ACKов) уже давно научились агрегировать для экономии времени.

Второе. Обратите внимание, как на диаграмме клиенты стоят ВОКРУГ точки. Обратили? Это тоже неспроста. Почти на всех диаграммах (кроме самой наглой маркетолохии) клиенты будут вокруг. Особенно, если диаграмма включает Beamforming:

802.11ac Wave2 Wi-Fi – не спешим (ч4) – MU-MIMO

Как вы думаете, хорошо ли будет работать формирование 3-4 НЕЗАВИСИМЫХ потоков данных, если все 3-4 клиента находятся в одном месте?

Третье и последнее. Обратите внимание, что ничего не говорится о поддержке со стороны клиента. Обратили? А она нужна! Чтобы это всё работало нужна поддержка клиентов. Без этого – ничего не будет. Впрочем, клиенты уже есть, вот, к примеру, список для Quallcomm:

Итого?

В целом, для того, чтобы MU-MIMO работал нужно следующее:

  • Поддержка клиентов
  • Преимущественно downstream трафик
  • Клиенты со всех сторон от точки
  • Клиенты не двигаются (тоже важно для Beamforming’а)

Всё это реально, и при таких условиях в реальной среде (не супер-специальной тестовой камере) общая пропускная способность в соте может достичь примерно 2.1x от обычного Single-User MIMO (именно около этой цифры колеблются отчеты и тестирования почти всех вендоров, презентуемые на реальных технических мероприятиях). Как видим – далеко не в четыре раза, но и не так бесполезно. При правильном дизайне сети через год-другой, когда MU-MIMO будет поддерживать большинство устройств от него будет польза. Если только к этому времени не выкатят 802.11ax Wave1 :)

Заключение

802.11ac Wave2 обещает много и частично выполняет обещания. Не так, чтобы он совсем бесполезен, но достичь даже 50% от новых заявленных скоростей будет практически нереально.

Из хорошего, это значит, что скорее всего не придется апгрейдить проводные сети и прокладывать новые кабели (а этим много стращали и даже придумали новый стандарт Ethernet на 2.5GBps чтобы лучше продавались коммутаторы). С другой стороны, может оказаться, что новые точки потребуют питания 802.3at PoE+, а на старом «обычном» 802.3af PoE будут работать не лучше (а то и хуже) старых.

В общем получается так же, как и с переходом с .11n на .11ac: если вам нужна скорость индивидуальных линков, и вы не строите беспроводные мосты – ничего нового вы не получите. Если вам нужна емкость (скорость по всей соте) – прирост будет. Но обязательно нужен пилот в вашем конкретном окружении и с вашими конкретными приложениями и клиентами, а то прироста может вообще не быть, или он не будет стоить потраченных денег.

Из альтернатив имеет смысл попилотить Wave1 или даже 802.11n, если цена привлекательна (Wave2 сейчас продается с большой наценкой, а Wave1 уже «не модно») и уже целиться на 802.11ax, обещающий реальные качественные, а не количественные, изменения.

Что думаете?

802.11ac Wave2 Wi-Fi – не спешим. Ч3 - каналы

В предыдущих частях мы рассмотрели обещания 802.11ac Wave2 и насколько они выполняются в плане увеличения числа потоков MIMO.

В этой части рассмотрим обещания в плане каналов. А именно:

  • Каналы 160Mhz: в два раза шире, чем 80Mhz Wave1
  • Дополнительные каналы в 5GHz: больше каналов – лучше плотность!

Начнем с простого: дополнительные каналы в 5GHz работают только в США. Нам это не светит. Закончили.

Теперь рассмотрим каналы в 160MHz.

В 802.11a/g каналы были 20 Mhz, в 802.11n – 20/40Mhz, в 802.11ac Wave1 – 20/40/80. Wave2 добавляет еще каналы в 160MHz, обещая за счет этого еще одно удвоение скорости. Получится?

Конечно получится. Вопрос только, сколько каналов мы сможем туда уместить. В регуляторном домене ETSI доступны следующие 5GHz каналы:

  • 36-48 (5170-5250 = 80MHz) Indoors
  • 52-64 (5250-5330 = 80MHz) Indoors/DFS
  • 100-140 (5490-5710 = 220MHz) DFS
  • 149-165 (5735-5835 = 100MHz) SRD (25mW)

Как видим, технически доступно 480MHz, что достаточно для 3 каналов по 160MHz. Прямо как в 2.4GHz, но в несколько раз быстрее (потенциально). Соответственно, как только мы начинаем использовать такие каналы – возникают проблемы с организацией частотного плана и перекрытием со старыми сетям 802.11a/n/acWave1.

Кроме этого, внимательный читатель заметит, что 480Mhz доступны не непрерывно, и реально 160MHz каналов можно уместить только два. Для решения этого вопроса в 802.11ac Wave2 сделали хитрую штуку: канал 160MHz не обязан быть непрерывным, но может состоять из двух блоков по 80Mhz. Таким образом гораздо легче «вписаться» в существующую среду.

Однако и тут дела обстоят не так просто. К примеру, в диапазоне «первого» 160MHz-канала 5170-5330Mhz для первой и для второй при работе вне помещения указываются разные требования. А учитывая то, как работает DFS надеяться на стабильную работу всех 160MHz не приходится. Аналогично для последнего 100MHz блока требования ETSI указывают макс мощность в 25mW (Short Range Devices) – как далеко будет такая точка добивать? (Справедливости ради отметим что для высокоплотной среды даже такая мощность может оказаться слишком высокой)

Еще одной проблемой широких каналов является помехоустойчивость. Шанс словить помеху или искажения на 160MHz естественно выше, чем на 20MHz. Конечно, часть проблем решается коррекцией ошибок на приемнике за счет избыточного кодирования. Но чем выше data rate, тем меньше устойчивости.

Напомним, что в Wi-Fi для разных скоростей используются разные схемы модуляции с разной степенью избыточности кодирования: BPSK, QPSK, QAM. При этом для высоких скоростей используется исключительно QAM. 802.11a/g использовал QAM-16 для достижения максимальности скорости. 802.11n опередил 802.11a/g за счет введения QAM-64, а 802.11ac добавляет еще более высокую QAM-256. Вот табличка из Wikipedia.

А вот картинка (источник) о том, как ведет себя QAM-64 на 20MHz канале в относительно чистой, но реальной, а не «стерильной» среде. Изображено распределение ошибки при передаче пакета (PER: Packet Error Ratio, 1 – 100% потерянный пакет) в зависимости от соотношения сигнал-шум (SNR, Signal-Noise Ratio). Здесь используется 802.11n 2x2:2 802.11n MIMO с 20MHz каналом и со следующими параметрами MCS:

  • MCS8: BPSK с 100% избыточности
  • MCS12: 16-QAM с 33% избыточности
  • MCS15: 64-QAM с 20% избыточности

802.11ac Wave2 Wi-Fi – не спешим. Ч3 - каналы.

Как видим, для BPSK при SNR20+ PER падает в 0 и пакеты пропадают очень редко. Для QAM-модуляций, в особенности для QAM-64, пакеты пропадают при любых условиях даже с 20% избыточностью кодирования. Можно ли это назвать стабильной связью? И это на 20MHz канале. Что будет на 80/160Mhz?

Стоит также напомнить, что более широкие каналы означают меньший уровень сигнала. Имея, скажем 100mW, при «размазывании» их по 160MHz полосы, естественно пиковые уровни будут меньше, чем при «размазывании» их по20MHz. Грубо говоря, каждое удвоение ширины – 3dB к уровню сигнала. Таким образом 160Mhz будет на 9dB слабее 20Mhz. Конечно, приемник тоже будет «собирать» сигнал с более широкой полосы, но шансы на искажение увеличиваются.

Так что о высоких скоростях на широких каналах лучше не думать.

Но закончить хочется на позитивной ноте. Хоть широкие каналы и далеко от того, что нам обещает маркетинг, польза от них есть, да и вреда почти никакого. В 802.11n широкие каналы работали очень редко – как только рядом появлялась точка неспособная понимать широкие каналы (802.11a/b/g) – приходилось сворачиваться на 20MHz и выжидать. Так что, к примеру, в густонаселенных местах они почти не работали. В 802.11ac это учли. Теперь есть такая штука как Dynamic Bandwidth Allocation, которая, по сути позволяет менять ширину канала попакетно. Таким образом даже 160MHz каналы могут быть использованы (хоть и редко). А если все рядом стоящие точки поддерживают эту штуку – они просто «распилят» общий широкий канал на несколько узких и будут передавать одновременно. При этом, если другие молчат, точка сможет передавать и на все 80-160Mhz. В общем, очень круто и своевременно!

Правда, и тут есть своя ложка дегтя: эту штуку должны поддерживать клиенты и соседи, что логично. Проблема в том, что она не вошла в обязательную часть 802.11ac Wave1. Есть Wave1 чипсеты, которые ее поддерживают, но не все. Так что пока большинство не переберется на Wave2 потенциал этой штуки полностью раскрыт не будет (но время от времени она все равно будет работать).

Итого.

В общем [BUSTED], но какая-то польза есть.

Важно понимать, что макс. скорость на макс. ширине канала – это утопия, и пока все (включая клиентов) не переедут на Wave2 – практически все профессионалы рекомендуют оставаться по-умолчанию на 20MHz.

Тем не менее, скомбинировав тот же низкоскоростной BPSK с широким каналом можно получить более высокую среднюю скорость и стабильность чем от двух узких каналов с QAM. Однако каждый случай будет уникален.

Что думаете?

В последней части рассмотрим MU-MIMO

802.11ac Wave2 Wi-Fi – не спешим (ч4) – MU-MIMO

802.11ac Wave2 Wi-Fi – не спешим. Ч2 - потоки

В прошлой части мы рассмотрели, что нам обещает 802.11ac Wave2. В этой рассмотрим, насколько данные обещания выполнимы.

4-8SS. Обещанные новые пространственные потоки MU-MIMO – это хорошо, но выполнимо ли? Тут есть много «но», но основных три:

  • Клиенты. Во-первых, для достижения высоких скоростей их должны поддерживать и клиенты (тут нужно сделать оговорку на MU-MIMO, но мы к нему вернемся). Если ноутбуки с 3SS мы еще видели, то телефоны и планшеты – самый массовый тип клиента – еле добрались до 2SS (да и то, в основном тоже для маркетинга). Выше лезть не позволяют ограничения по питанию, что приводит нас к следующему пункту.
  • Питание. Со времен выхода первых точек 802.11n одним из важных конкурентных факторов для производителей WLAN-оборудования была возможность работы от 802.3af (PoE). 802.3at (PoE+), конечно, лучше, но может повлечь замену не только свичей, но и UPSов, электрооборудования, систем охлаждения и т.д. Понятно, что каждый новый SS – это, фактически, дополнительное мини-радио. А радио – основной потребитель энергии. Плюс, возросшие скорости требуют более мощных процессора и памяти, особенно с учетом новомодных штук типа Application-Layer Firewall’ов. Какой мощности должен быть процессор, способный проверять на прикладном уровне 7.62Gb трафика в секунду? И питаться от 802.3af?
  • Среда. И последнее. Для высокой скорости нужен качественное (и устойчивое) соотношение сигнал-шум (для того, чтобы работали самые быстрые MCS) и благоприятный multipath (чтобы потоки таки разнеслись в пространстве и сошлись на клиенте). А это, как-бы, взаимоисключающие требования: для хорошего и стабильного сигнала нужна прямая видимость. А при прямой видимости – какой multipath? Мы уже это проходили с выходом точек 802.11n 3SS, когда диаграммы самих же вендоров показывали, что новые скорости достигаются только в 10-15м от точки. Если третий поток добавить было так сложно – как, думаете, обстоят дела с четвертым? С пятым? С восьмым?

В общем, надеяться на высокие скорости от новых потоков, особенно от 8SS могут только создатели беспроводных мостов: две точки смотрящие друг в друга кучей супер-узконаправленных антенн (тарелки и т.д.), никаких ограничений по питанию (всё равно требуются спец-БП для мощных радио) – можно запустить 4 потока на 8 антеннах и получить отличную избыточность (=помехозащищенность, дальность и т.д.) сигнала.

Остальным придется выбирать. В принципе, дополнительные антенны – это хорошо (если они работают от 802.3af – многие вендоры просто отключают радиоцепи при работе со стандартным PoE, но забывают об этом сказать в пресс-релизе). Это избыточность сигнала. Это лучшая помехозащищенность. Это в целом немного более быстрые скорости если у клиента достаточно приемных антенн. И даже если антенн недостаточно – всё равно чуть более быстрые скорости (более качественный beamforming). Это, в конце концов, лучший потенциал для MU-MIMO (о нем позже).

Всё это в целом позволит немного поднять емкость сети, но надеяться на 33%+ прироста я бы не стал.

Вердикт: [BUSTED]. А вы как считаете?

В следующей части напишу о каналах. Много букв получается.

802.11ac Wave2 Wi-Fi – не спешим. Ч3 – каналы

802.11ac Wave2 Wi-Fi – спешим или не спешим?

Устройства 802.11ac Wave2 уже доступны на каждом углу обещая тот самый «гигабитный» Wi-Fi. А для тех, кто помнит, что «гигабитный» Wi-Fi нам уже обещали 802.11ac Wave1 – обещают «мультигигабитный» Wi-Fi. Давайте разбираться, что мы получим на самом деле.

Для начала, что же нового приносит Wave2?

  • 4SS+: новые чипсеты Wave2 поддерживают четыре и выше пространственных потока MIMO (Spatial Streams), что как-бы на 33%+ быстрее Wave1 с 3SS.
  • Каналы 160Mhz: в два раза шире, чем 80Mhz Wave1
  • Дополнительные каналы в 5GHz: больше каналов – лучше плотность и емкость сети!
  • MU-MIMO: самая главная и активно продвигаемая фишка. Традиционная Wi-Fi сота – это хаб. Можно иметь точку с суперширокими каналами, супербольшим количеством потоков и т.д., но если клиент поддерживает только один поток на 20Mhz и на самой медленной модуляции – весь остальной потенциал точки будет потрачен впустую. В зависимости от комбинации точки и клиента неэффективность может составлять 70%+ доходя в крайних случаях до 90% потерянного потенциала (=выброшенных на ветер денег). MU-MIMO (Multi-User MIMO) обещает если не решить, то хотя бы улучшить проблему, обеспечив параллельную передачу данных нескольким клиентам. Таким образом, наш хаб как бы превращается в свитч и мы уже не теряем весь тот (оплаченный) потенциал.

Во всяком случае, в пресс-релизах и маркетинговых материалах все именно так. Еще любят добавить цифр:

  • взять пропускную способность 802.11ac Wave1 - 1.3Gbps
  • удвоить за счет новой ширины каналов (80 -> 160): 1.3*2 = 2.6Gbps
  • добавить новые потоки (Wave1 3SS -> Wave2 8SS): 2.6/3*8 = 6.93 Gbps
  • поделить на пропускную способность 802.11n (600Mbps): 6.9/0.6 = в 11.5 раз быстрее!
  • 802.11ac работает только в 5GHz, но мы добавим на всякий случай 2.4 радио (которое работает в 802.11n до 600Mbps) и получим 6.93+0.6 = 7.53 ~=7.6 Gbps (на точку).
  • напомнить о необходимости поменять все свитчи на 2.5G или 10G, чтобы не платить за прокладку новых кабелей.

А что на самом деле? Какие их этих цифр «честные»? Какие полезные? Какие реальные? Напишите в комментариях свои соображения, а я на выходных опубликую вторую часть с подробным анализом.

802.11ac Wave2 Wi-Fi – не спешим. Ч2 - потоки

Так ли приватен HTTPS?

Недавно в одном из прочитанных блогов увидел интересное утверждение (в моем вольном переводе):

Думаете, когда вы работаете с онлайн-банкингом из офиса, у вас сквозное безопасное соединение? Подумайте еще разок.

Достаточно, чтобы заинтересовать и немного покопать. Оказалось, что в "насквозь безопасное" HTTPS соединение можно врезать как минимум двух посредников (Man In The Middle). Правда, оба должны быть Trusted (TMITM), так что не надо сильно паниковать. Пока что.

Вариант 1: корпоративный/операторский файрвол или прокси

В корпоративных сетях пользователи обычно выходят в Интернет через прокси, который может быть задан явно или неявно (transparent или просто продвинутый firewall). Это необходимо для поддержания хотя-бы минимального корпоративного контроля над трафиком (фильтрация нежелательных сайтов/скриптов/рекламы, антивирусные проверки, кеширование и т.д.) и, в принципе, логично.

Абсолютно понятно, как это работает для нешифрованного HTTP, а вот с HTTPS - понятно не все. Ведь HTTPS как раз и предназначен для защиты от "врезания" в сессию и перехвата трафика: данные шифруются, а аутентичность сервера проверяется сертификатами. Так что, возникают как минимум два вопроса:

  1. Почему я должен доверять сертификату прокси?
  2. Даже если я доверяю сертификату прокси, он же выпущен на имя прокси, а не на имя моего банка - как он может сработать?

Выходит, что может.

Первый вопрос вообще не возникает, если в компании развернута собственная инфраструкра сертификатов и есть свой CA. В таком случае, сертификат этого CA будет установлен как доверенный на каждой рабочей машине, и всё, что будет подписано этим же сертификатом (наш прокси) также будет доверенным. Именно из-за этого подобное "доверенное" (Trusted) внедрение и становится возможным в этом сценарии.

Но что делать с неправильным именем в сертификате? Существует (и довольно давно) класс программ типа MITMproxy или HoneyProxy, которые этот вопрос успешно решают. Их основная функция - читить в Apple GameCenter генерировать сертификаты на лету! Прокси устанавливается в качестве промежуточного CA (подписанного Enterprise Root CA) и динамически генерирует сертификаты (для себя же) на любое имя. Таким образом, клиент думает, что он общается с банком, хотя, на самом деле, его HTTPS сессия заканчивается на прокси. Подробности тут.

image

Так что, исходное утверждение оказалось верным, и верить рабочим HTTPS-соединениям можно лишь настолько, насколько можно верить своему ИТ-отделу. Или же использовать браузер вроде Firefox, у которого имеется свое, независимое от ОС, хранилище сертификатов и поддержка Certificate Pinning (не так давно ставшая популярной в браузерах). Ну, или, конечно же, не использовать рабочие машины в рабочей сети в нерабочих целях, но кто будет следовать этому глупому правилу? VPN тоже может помочь, если он не на основе SSL.

То же самое может произойти если использовать смартфон "от оператора" с операторской прошивкой - вероятность нахождения на нем по умолчанию доверенного сертификата для всей инфраструктуры оператора близка к 100%.

Вариант 2: Облачный бесключевой прокси CloudFlare

Хорошо, администратор моей работчей сети может мониторить мои соединения с рабочей машины. Ну да ладно. Во всяком случае, целевой сервер, к которому я подключаюсь должен быть аутентичным - иначе прокси запаникует и не построит до него HTTPS-сессию (если только админы не накосячили с настройкой). В свете недавнего анонса Keyless SSL от CloudFlare, похоже, это уже тоже не факт.

image

Технические подробности можно почитать тут. Для нас важно то, что в данном сценарии уже целевой сервер (тот же онлайн-банкинг), оказывается, уже банку не принадлежит! Хорошая новость в том, что он принадлежит кому-то, кому банк доверяет.

Товарищи из CloudFlare разработали способ представляться HTTPS-сервером заказчика без необходимости подделывать сертификаты или даже подписываться ключами заказчика. По факту, как раз проверка аутентичности проводится с сервером банка, но как только она пройдена - сеанс устанавливается с доверенным сервером CloudFlare. Цель благородна - разгрузка HTTPS-трафика клиентов и защита от DDoS-атак. Сколько времени понадобится на изобретение метода имперсонации целевого сервера без необходимости получать его сертификаты и ключи (или как быстро "органы" разных стран затребуют себе бекдор-доступ) - кто его знает. Надеюсь, достаточно долго.

Итого

В, казалось бы, "безопасном от и до" HTTPS соединении могут успешно поселиться как минимум два посредника. Оба должны быть доверенными, но доверяет им ваш админ, ваш босс, ваш банк, ваш магазин - только не вы. Если вы думаете, что в Интернете еще есть 100% приватность - подумайте еще разок.

А вы знаете какие-то еще методы атак на HTTPS?

P.S. Оригинал тут.

802.11ad (WiGig) — дальность и полезность

На фоне объявления QCA (Quallcom Atheros — один из лидеров в Wi-Fi чипсетах) о покупке Wilocity (один из разработчиков WiGig чипсетов) поднялась волна энтузиазма по поводу 802.11ad. В частности, возникла мысль построить на 802.11ad систему видеонаблюдения — ведь с 7Gbps пропускной способности можно снимать видео в высоком разрешении с большого числа камер! Давайте разбираться:

802.11ad (WiGig) - дальность и полезность

Согласно Wiki, минимальный уровень сигнала для работы 802.11ad на минимальной скорости (385Mbps PHY на секундочку!) равен 68 dBm.

Согласно вот этой статье (хорошая статья по 802.11ad, кстати), максимальная мощность передатчика 802.11ad составляет 10 dBm. Это, кстати, в 10 раз меньше, чем в Wi-Fi.

Потери при распространении сигнала FSPL на всего лишь 10 м для 60GHz (в которых работает 802.11ad) составляют 88 dB (посчитано на одном из множества калькуляторов FSPL). Плюс, есть еще дополнительные потери из-за резонанса с молекулами кислорода, но давайте это опустим.

Построив простую формулу бюджета мощности канала, получим, что для работы 802.11ad на минимальной скорости на расстоянии 10 м нам нужно усиление в канале порядка 10 dB. Подробности и матан тут.

Откуда же этим 10dB взяться? Либо из усиления антенн, либо от beamforming'а, который так радужно расписывают маркетологи от 802.11ac и 802.11ad. Однако, антенны мобильных устройств обычно отличаются отрицательным усилением, так что тут нам ловить нечего. Beamforming (как показали результаты 802.11ac) может выдать 3-5dB сверху. Т.е. на передающую антенну точки доступа остается 5-7 dB.

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

Так что, уже на расстоянии 10 м работа 802.11ad проблематична.

Можно ли его использовать для стриминга видео? Да!

  • Стримить видео с ноутбука на внешний монитор или проектор на расстоянии 2-3 м.
  • Стримить видео с планшета на телевизор без кабелей или переходников.
  • Стримить видеофайлы на внешнее хранилище для бекапа.

Стримить видео с камеры наблюдения? Ну, если от камеры до точки <10м и точно нельзя бросить провод... :) Вторым вариантом будет направленная антенна на камере с большим коэффициентом усиления — жизнь (и кислород) покажет, насколько это реально.

802.11ad (WiGig) - дальность и полезность

С другой стороны, такая малая дальность — сущее благо для домашнего пользователя: сосед за стеной наконец-то перестанет "забивать мой Wi-Fi своим Wi-Fi". Аналогично, у корпоративных админов WLAN появится шанс увидеть как вся BYODшная мелочь убирается из и без того загруженного диапазона 2,4 ГГц (и заодно, не так быстро замусоривает 5 ГГц), что тоже неплохо.

В общем, как говорят буржуи: "Right tools for the right job" (картинка кликабельна).

 Что вы думаете по поводу 802.11ad?

802.11ad (WiGig) - дальность и полезность

MWC2014: MIMO 2x2:2 в телефонах, роутеры в SFP-модулях...

Среди множества анонсов MWC2014 хочу выделить два. Один, погромче, от Broadcom, он сам по себе еще наделает много шуму. Второй, потише, от Huawei - там всё "без шуму и пыли", но очень интересно.

Broadcom анонсировала WLAN-чипсет для мобильных устройств с поддержкой 802.11ac 2x2:2 MIMO (867Mbps), вызвав немалый ажиотаж в прессе. Давайте разбираться.

Итак, 867Mbps, говорите?

  • У кого-то дома есть гигабитный интернет?
  • Кто-то видел насколько быстрый хотспот?
  • У кого дома есть NAS для фильмов с реально быстрым RAID'ом? Даже одиночный SSD не всегда может отдавать данные так быстро.
  • Если SSD в ПК не может читать так быстро, то у кого еще есть уверенность, что телефон сможет это писать так быстро на встроенную флеш-память (не говоря уже о карточке)? Имеющиеся у меня данные показыват скорости порядка 35-65Mbps для среднестатистического телефона.
  • Две антенны = как минимум в два раза больше потребляемая мощность. Как это скажется на сроке работы от аккумулятора?

Какой же тогда от него толк, говорите?

Ну, для начала, если что-то передавать в два раза быстрее - это займет в два раза меньше времени. Так как ключевым ресурсом Wi-Fi сети является именно эфирное время - то возрастет общая емкость ячейки (количество клиентов или средняя скорость на клиента при том же количестве). Заодно, т.к. антенны меньше времени заняты передачей, можно сэкономить немного энергии. Но это всё только при небольшого объема передачах (браузинг), которые отправятся напрямую в ОЗУ телефона (если производитель такую фичу реализовал). Да и то, нужно же еще, всё-таки, данные с такой скоростью отдавать - а это значит буферизация на точке, и приличная, а то никакой разницы с "обычным" 802.11ac@433Mbps видно не будет.

 А вот что реально может помочь, так это технологии MRC и STBC, в сочетании с режимом 2x2:1 или, вообще, 1x2:1.

  • При двух приемных антеннах MRC позволяет путем математики рекомбинировать исходный поток данных из копий принятого сигнала, улучшая чувствительность приемника ("среднетемпературно-по-больнице" на 3дБ).
  • При двух передающих антеннах STBC позволяет путем математики передать один поток данных так, чтобы MRC получил сигнал в наилучшей форме, добавляя "математического" усиления к передаче (еще примерно столько же).
  • В итоге, получаем значительное улучшение параметра Rate-over-Range за счет лучшего соотношения сигнал/шум. Что, согласитесь, немаловажно для небольшого по размерам устройства, большая часть антенн которого закрыта ладонью пользователя.

Итого, равно как и с самим 802.11ac, основное улучшение здесь не скорость (которую нам будут продавать маркетологи), а дальность и чистота сигнала. Опять же, чисто из батарейных соображений, мне интересно сравнить этот 2x2:2 и 1x2x1 (на прием-то меньше энергии уходит) и посмотреть, стоит ли овчинка выделки. Время покажет - вроде-бы такой чипсет стоит в Galaxy S5.

А вот что реально было пропущено большинством обозревателей MWC под шумом анонсов смартфонов, так это эта штука:

MWC2014 MIMO 2x22 в телефонах, роутеры в SFP-модулях..

Это - полноценный роутер в формате SFP. С поддержкой IPv6 и даже SDN. Уровень всех этих поддержек, конечно же, надо бы проверить - но сама идея! Представляете, что можно потенциально с такой штукой сделать, особенно, добавив к ней WWAN-модем?

Что в Облаке тебе моем?...

В соседней теме про "облака" развернулись занимательные дебаты, из которых пока ясно только одно - понимание термина "облако" разнится у участников довольно сильно.Что в Облаке тебе моем?...

Вопрос не так прост как кажется: один из наиболее часто упоминаемых в данном контексте документов - NIST SP 800-145 (The NIST Definition of Cloud Computing от Национального Института стандартов и технологий США) прошел, если верить пресс-релизу, 15 черновых стадий. И это при том, что в данном семи(!)страничном документе всего две(!!) страницы "полезной нагрузки" с дюжиной определений (два из которых, как по мне, избыточны, если только их не ввели исключительно для использования в 800-146). И все равно находятся несогласные.

Посему, хочется использовать этот пост как площадку для вопроса уважаемой публике: а что для вас лично значат термины "облако" и "облачные вычисления"? Тождественны ли они? По мере развития дискуссии буду поднимать наиболее интересные мысли в тело поста.

Мысли об Amazon AppStream и облачном Remote Desktop

В прошлом месяце Amazon представила AppStream, позволяющий выполнять и рендерить приложения в облаке AWS и отображать результат на обычных потребительских устройствах. Вскоре после анонса в Сети появилось немало статей, как бы подразумевающих, что теперь можно решить все вопросы просто накупив планшетов и используя AppStream в качестве некоего облачного Remote Desktop. Идея, безусловно отличная, но всё так просто...

Во-первых, многие (в т.ч. автор) после анонса пропустили тот факт что для работы AppStream необходимо еще написать клиентское приложение... Давайте посмотрим насколько просто запустить саму идею "облачного Remote Desktop" в качестве замены парку ПК, решения вопросов Desktop Support и мобилизации в целом. Равно как и с BYOD, здесь нужно хорошо понимать все детали при внедрении проекта и требования к клиентской части.

1. Безопасность. Как ни крути - вопрос номер 1 для Enterprise (после стоимости, конечно). Опустив аспект "доверия облакам" в целом, сосредоточимся на мобильности. Да, я теперь могу стримить свое жутко древнее HR-приложение прямо из облака на телефон/планшет HRов. Но как убедиться, кто данные этого приложения не утекут, когда этот телефон/планшет забудут в такси? Помнится, было немало опросов, показавших, что большинство пользователей даже не ставят блокировку экрана, т.к. это неудобно (я, кстати, один из них, в определенных случаях).

Не то, чтобы мы имеем дело с неразрешимой проблемой, но уже, получается, что для решения этого и других вопросов безопасности (шифрование данных, VPN, управление ключами и сертификатами и т.д.) в дополнение к подобному сервису нужно разрворачивать MDM. И разворачивать грамотно: с грамотной политикой, убедившись, что мобильные устройства полноценно поддерживаются MDM-системой (что требует авторизации производителя MDM производителем устройства для получаения root-прав MDM-агентом). В общем, вместо одного проекта на руках уже два. А на самом деле - три: кто еще должен написать политику безопасности в области мобильности. Причем политику, которая балансирует между интересами организации (безопасности) и пользователя (удобство), которую потом нужно утвердить, продвигать в массы ("и с чего это я должен считаться с глупыми правилами конторы?"), и следить за исполнением (причем и в части monitoring и в части enforcement). Как по мне, этот третий проект по сложности будет равен двум первым вместе взятым, если честно.

2. Продуктивность. Большинство старых приложений писались под клавиатуру и мышь, с комбинациями типа "Ctrl-Click" и "Alt-Shift-PgUp". Стримить такое на планшет возможно, а вот работать с ним - не очень :) Получается, нужно вкладывать в интерфейс клиенского приложения функции ремаппинга клавиш, переформатирования экрана, настраиваемой экранной клавиатуры с макросами и прочими "прокладками" для адаптации десктопных приложений к мобильному миру.

Тут тоже ничего страшного в принципе нет большинство из этих прокладок даже не надо изобретать - они уже реализованы в той или иной мере в специализированных продуктах. Так что если подойти к вопросу с умом можно значительно продлить срок жизни того самого "древнего HR-приложения". Но вот вам еще один проект впридачу, со своими проблемами и затратами (на внедрение и поддержку).

3. Потеря работоспособности. Та же давно известная проблема из разряда "модное против защищенного", "консумерское против корпоративного" и т.д: когда пользователь напортачит со своим устройством и из-за этого не сможет выполнить работу к заданному сроку - что делать? А что делать, если устройство глюкануло посреди какой-нибудь запутанной транзакции? Может AppStream держать сеанс открытым до возвращения пользователя? Возможно ли доработать клиентское ПО, чтобы по возвращении пользователь подключился именно в тот самй прерванный сеанс (в случае многосессионности)? Или придется привлекать админов, откатывать транзакцию, подчищать всё (и надеяться, что это не затронуло других работников) каждый раз, когда кто-то выпадает из зоны покрытия? Тут уже никакие доработки клиентского ПО не помогут.

Подводя итоги: AppStream - отличная идея с огромным потенциалом в целом (стриминг игр) и для корпоративного ИТ (и по разгрузке поддержки, и по мобилизации и повышению работоспособности сотрудников). Главное - не перевозбуждаться от маркетинга и трезво оценивать все нюансы при проектировании внедрении. А то получится как с BYOD :)

Анонс Apple — тормоз "прогресса" Enterprise WLAN?

Буду краток. Когда анонсировали новые iPhone, многие отметили отсутствие 802.11ac (есть, скажем, в главном конкуренте — SGS4). Особенно это отметили производители беспроводного оборудования Enterprise-класса — для них это означало, что "лЁгко" продать 802.11ac не получится — придется реально обосновывать необходимость в замене.

Для сравнения, когда iPhone и iPad стали поддерживать 802.11n — убеждать о необходимости перехода почти не приходилось. Но оставалась надежда: "Вот, Apple анонсирует новые iPad, там Wi-Fi чип, обычно, более продвинутый — там точно будет .ac, и заживем!" — говорили многие вендоры и околовайфайные эксперты. Не состоялось. Что еще раз поднимает вопрос, а так ли нужен 802.11ac Wave1 сейчас и вообще? Что можно сказать точно, что новый анонс не добавит позитивной динамики рынку 802.11ac. Хорошо, если не убавит.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT