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

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

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

В прошлом месяце 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 :)

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

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

На днях Motorola Solutions сделала знаковый анонс, объявив новое устройство и многое другое. Интересно, что всё это у Motorola уже было несколько лет назад — почему же именно сейчас я не постеснялся назвать этот анонс "знаковым"?

Сам анонс состоит из трех (четырех по версии маркетологов) компонентов:

• Смартфон "для работы" TC55 на Android.
• Обновление самой платформы Android для устройств Motorola и Обновление расширений Mx, включая прошивку для устройства, прежде работавшего только на WM (это посчитали за два обновления).
• И большое обновление кросс-платформенной среды разработки, с поддержкой всего вышеперечисленного.

Громкий компонент анонса.

Начнем с самого "громкого" (хоть и не самого важного, с моей точки зрения) — анонса TC55, который должен появиться в продаже в Ноябре.

Пред-скриптум: пожалуйста, перед тем как писать "странный смартфон, я бы себе такой не купил" — прочитайте этот пост.

Когда-то я писал о Motorola ES400—  инициативе Motorola (тогда еще не Solutions) по решению проблемы проникновения не-корпоративных смартфонов на корпоративный рынок (о чем я тоже писал). Свежий пример, почему это проблема (масштаб внедрения — 640 000 устройств!) — тут. Я не знаю, насколько хорошо ES400 показал себя "в поле" (всё-таки, не MC75/65/67), но продавался он огромными партиями и достаточно успешно: даже сумел отъесть часть доли "китайцев" (как минимум, в западной Европе), а конкуренты "внезапно" выпустили свои аналоги. Начало было положено.

Что мы имеем три года спустя?

• С одной стороны, технологическая база уже свободно позволяет индивидуальному пользователю достаточно удобно работать со смартфона/планшета: удобные ОС, мощное железо, хорошее покрытие и вменяемые цены на мобильный интернет. Активно перемещающиеся сотрудники (будь они сейлы/констультанты, или курьеры/мерчендайзеры) уже привыкли к постоянной доступности онлайн-подключения к рабочим ресурсам. Да и работодатель от них ожидает того же.
• С другой - предприятия наигрались в BYOD, и поняли, что это не так уж просто: все эти псевдозащищенные устройства с несовместимыми консумер-ориентированными ОС создают огромную проблему и для разработки, и для поддержки приложений, и для управления всем этим (зоо)парком, если говорить о внедрениях, где счет идет на сотни и тысячи устройств.

Всё это создает удачный момент для того, чтобы выйти с новой моделью "бизнес-смартфона", уже на новой ОС (Android). Особенно, если учесть, что при выходе ES400 в 2010 обещали, что фаза активных продаж и развития модели будет длиться 3 года (и еще 2 года — поддержка). :) Производить железо с бизнес-акцентом Motorola умеет. Опустив гигагерцы, гигабайты, которые можно посмотреть в спецификации, сосредоточусь на интересном, и добавлю несколько картинок.

Выглядит как нормальный смартфон, а не кирпич. Симпатичные разноцветные чехольчики прилагаются :)

Всё, что мы привыкли видеть в смартфонах на Android на месте: Wi-Fi 802.11n, BT 4.0, разъемы USB и MicroSDHC, камера 8MP, GPS/ГЛОНАСС, датчики освещенности, присутствия и т.д.. При этом также есть поддержка LTE 4G, NFC, Wi-Fi работает в 5ГГц, помимо стандартных 2.4, BT поддерживает приличное количество профилей (около 13). Из потенциальных минусов: "всего" один гиг памяти, "всего" два ядра и Android 4.1.2 — современные игры будут тормозить. Но кого это волнует? Работник должен работать! Всё остальное в TC55 подчинено этому принципу:

"Двухрежимный" емкостный тач-скрин, с которым можно работать в перчатках и без, со стилусом или без, под дождем или мокрыми руками. Яркость дисплея в 700NITS — для работы под ярким солнцем.

Рабочая температура от -10 °C. Пыле- влагозащита IP67, устойчивость к падениям с высоты 1.2 м на фанеру (посмешили, но налицо прогресс: у MC35 было "90 см на ковер", у ES400 было "100см на ламинат" :) ), стекло Gorilla Glass 2.

Сканер штрих-кодов 1D нового поколения  и камера, оптимизированная для сканирования документов и 2D-ШК (фокусное расстояние + тюнинг софта)

Аккумулятор 2940/4410(!) мАч. Зарядка через контактные площадки, а не разъемы ножевого типа (как стандартные MicroUSB) — не разнашивается со временем, если падает с подключенным зарядником — ничего не выламывается. Но нужен специальный зарядный кабель (идет в комплекте). Модульная система кредлов, позволяющая комбинировать места для зарядки TC55 с MC40/MC45 и зарядниками для батарей. Устройства можно заряжать / менять батарею / ставить в кредл прямо в чехле. Всякие полезности типа серийного номера вставленного аккумулятора и сколько ему еще жить осталось (в циклах полного заряда/разряда). Звучит не особо потрясающе, но неделю назад проводил тренинг в одной куръерской компании — они были ОЧЕНЬ рады, узнав, что такое у них теперь есть, т.к. с бардак с батарейками у них дошел до такого состояния, что начальство просто отказалось впредь покупать запасные.

Штатно два года расширенной гарантии с 3-дневным сроком ремонта. Попробуйте такое получить от Apple или Samsung :)

Важный компонент анонса.

В общем, железка довольно многообещающая, выглядит неплохо, про нее еще немало  напишут обзоров (пока можно посмотреть видео здесь), продаваться будет на ура, но дело не в железе..

Знаковость происходящего совсем не в нем, а в остальных компонентах анонса.

Android с корпоративными расширениями Mx. Почему Android, думаю, понятно. В чистом виде Android не особо подходит, но есть возможность его "доработать напильником", что Motorola и сделала, создав свою сборку из Android Open Source Project, снабженную набором расширений Mx. Mx направлена на закрытие следующих важных вопросов: безопасность, управление приложениями и устройством, сбор данных, связь. При этом активно подчеркивается, что это "расширения", а не полная пересборка, и проблем с совместимостью быть не должно. Ниже иллюстрация, по клику откроется PDF, из которого она была взята.

Про Mx нужно писать отдельную статью, пока хочу обратить ваше внимание на следующее:

До этого момента поддержка Android в Enterprise-сегменте была на уровне "давайте попробуем". У той же Motorola устройства на базе Android уже есть несколько лет (ET1, MC40), да и платформа Mx развивается уже два года. Но то, что я видел эти два года, было больше похоже на программу полевых испытаний — недоделанные фичи, частичные релизы, изменения в функциональности и архитектуре. То же самое было и у других вендоров — 1-2 устройства с наспех сделанным портом AOSP без планов поддержки и развития.

Даже было понятно, почему именно так: новые релизы Android выходили с ужасающей (корпоративного производителя) быстротой, а сама платформа была довольно корявой. Но посмотрите на ветку 4.x: версия 4.0 вышла в 2011 г., 4.1 — в 2012 г., и до 2013 г. поднялась аж до 4.3, даже особо не сменив наименование. Android 5.0 вообще переименовали в 4.4. Google явно унялась, и платформа, начиная с 4.1, стабилизировалась.

Теперь же, появился вендор, который явно ставит на Android. 

• Есть внятная линейка: КПК MC40, смартфон TC55 и "тяжелый" защищенный MC67 (WM/Android), плюс планшеты ET1N0(Wi-Fi) и ET1N2 (Wi-Fi+3G).
• Есть свой "Enterprise Linux" в виде Android с Mx.
• Есть программная платформа управления WM, Android и некоторыми консумерскими устройствами в виде SOTI и MSP.
• Есть прикладная платформа построения универсальных приложений в виде RhoMobile. Наличие такой кросс-платформенной среды позволяет заказчикам легко решить проблему миграции и разработки для зоопарка платформ (как в случае миграции с Consumer Android/Apple на Enterprise Android, так и в случае миграции с WM/WEHH/CE).

Как ни крути, Motorola Solutions на рынке мобильных устройств для работы - как Cisco на рынке сетевом, и ее действия окажут значительное влияние на сам рынок. После такого массированного анонса можно признать, что Android (после некоторой доработки напильником) таки годен для "взрослого" промышленного применения. Так что корпоративному Андроиду быть. А с ним быть и следующему этапу консумеризации ИТ. Не напоминает то, что произошло с мейнфреймами и рабочими станциями?

Будет ли корпоративный Android успешнее корпоративного Linux — еще вопрос, хотя, похоже, MS старается сделать для этого всё :) 

Ваше мнение?

P.S. Поскольку я тут делаю далеко идущие выводы, на всякий случай заявлю, что всё это — мое личное мнение, которое может расходиться с официальной позицией Motorola Solutions.

Так как никто ничего не пишет об использовании планшетов в корпоративном (уточняю: "Enterprise"/"бизнес")  мире, решил, что кто-то должен что-то написать. :)

Всё, указанное выше - реальные внедрения с использованием решений как бизнес-класса (Motorola, Getac, Panasonic, Motion Computing) так и консумерского (Apple, Samsung, etc) под управлением самых разных ОС. Распространяться на тему Consumer vs Enterprise не буду, т.к. уже было, и с того времени не изменилось ровно ничего. Примеры приведены навскидку, наверняка их гораздо больше.

Workforce Management

"Тактическое" управление персоналом (в отличие от HR).

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

Потребление информации

Врачи используют планшетки для быстрого получения данных рентгена и ряда сходных задач.

Строительно-инженерные конторы (стройка, ремонт лифтов/канализаций/кондиционеров) . Тоже ясно зачем. На YouTube полно видео Getac из Британии.

Про пилотов, загоняющих полетную документацию на планшет не писал только ленивый.

Очевидное и невероятное

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

• Медсестры посещающие больных - нужно заполнять кучу документации, до этого таскались с нетбуками. Дальше, думаю, логика ясна. Там даже раскладку экранных форм менять не пришлось. Британия.
• Контролеры в общественном транспорте, проверяющие e-билеты. Планшет нужен был т.к. у них там какие-то dashboard'ы, которые иначе никуда не влезают. Голландия.
• Видел курьера (а-ля FedEx/TNT/DHL) с защищенным планшетом, но не понял, зачем ему именно планшет. Возможно, всё-таки, большой экран удобнее для навигации по городу, и т.д
• Мобильный POS. Даже для iPad их уже написано немало. Не для развлечения же.

Когда-то давно еще я писал о бутике, где использовали таблеки для "модного" способа показать элементы коллекции, не присутствующие в магазине и сделать виртуальную примерку.

А, ну и показ презентации с планшета для тех, у кого нет ДУ для компьютера, конечно же :)

Ну, а если вы - Газпром, то вот: http://www.forbes.ru/news/242191-gazprom-zakazal-planshet-dlya-millera-z...

Итого

Горячо поддерживаю предыдущего оратора в его утверждении, что для многих людей настоящая работа - не за компьютером. При этом полностью согласен, что маркетинг буллшита было полно, равно как и с BYOD. Но пока маркетологи и критики распространяются, те, кому это действительно было нужно, уже сделали выбор и внедрили.

Если вам интересно почитать подробности про какой-либо тип внедрений - пишите в комментарии - постараюсь набросать небольшую заметку.

В прошлой статье мини-цикла мы говорили о 802.11ac, в этой — поговорим о сертификации Voice Enterprise: что это такое, и зачем она нужна.

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

Технологии более-менее качественной передачи голоса по Wi-Fi существуют достаточно давно, но построение качественной сети для VoWLAN до сих пор является весьма тяжелой задачей. И даже не из-за тонкостей радиопланирования и тюнинга QoS – банально, проблемой является подбор железа!

• Поддерживает ли инфраструктура все нужные технологии? Используются ли при этом стандартные или проприетарные механизмы?
• Тестировались ли стандартные механизмы на совместимость? Какие известны косяки?
• Будем ли мы использовать стандартные или проприетарные клиентские устройства?
• Поддерживают ли клиенты все нужные технологии? Где взять эту информацию? (Если для инфраструктуры Enterprise-класса, документация найдется всегда, то для всяких Android-трубок найти ее очень сложно.)
• Поддерживают ли голосовые приложения все нужные технологии?
• И что это за «все нужные технологии» вообще?

История проблемы.

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

• Качество: качество голоса должно быть хорошим на протяжении всего звонка в условиях любой нагрузки на сеть. С точки зрения услуги, качество голоса обычно определяется критериями R-Value или MOS. С точки зрения сети, для обеспечения данного требования поток данных для каждого клиента должен характеризоваться низкими значениями задержки, джиттера и потери пакетов.
• Сосуществование с остальным трафиком: в большинстве корпоративных сетей Wi-Fi не будет использоваться только для голоса – будут и другие применения. Так что, необходимы механизмы мирного сосуществования с трафиком других приложений, которого, весьма вероятно, может быть в разы больше.

В принципе, этого достаточно: нам нужна качественная услуга, которая уживется с уже существующими приложениями в сети. Как это транслируется в технические требования к беспроводным клиентам и инфраструктуре?

• Приоритезация. Прежде всего, необходимо назначать и учитывать приоритеты разных пакетов. В Ethernet для этого есть 802.1p. В Wi-Fi – 802.11e, также известный как сертификация WMM (Wireless MultiMedia). В отличии от 802.1p, где определено 8 классов трафика, в WMM их всего четыре: Voice, Video, Background и Best Effort. Голосовой трафик (AC_VO) имеет наивысший приоритет. WMM является сертификацией Wi-Fi Alliance, и на их сайте в базе данных можно посмотреть, какие устройства официально были протестированы на корректную поддержку WMM. Однако, одной приоритезации для полноценного QoS недостаточно.
• Управление полосой пропускания. Во-первых, как и в проводном QoS могут быть необходимыми такие функции как резервирование и/или ограничение полосы пропускания на разных уровнях (точка, WLAN, клиент, и т.д.). Во-вторых, беспроводные сети мобильны и клиенты в них перемещаются. В данной ситуации при роуминге клиенту очень важно попасть на точку, обладающую достаточным количеством свободного ресурса для «продолжения разговора». Иначе звонок может оборваться банально потому, что мы попали на перегруженную точку. Данная технология требует корректной поддержки со стороны и инфраструктуры и клиента. Клиент должен уметь опрашивать соседние точки перед роумингом (задумайтесь, при этом соседние точки могут быть на других каналах!) и выбирать свободную (для этого точки должны рапортовать свою загруженность). Однако, такая схема довольно сложна, и традиционно в Wi-Fi никто не верит в корректно работающие драйвера на клиентах. Поэтому пошли другим путем: инфраструктура должна уметь понимать, что требуется клиенту для полноценной работы (клиент сообщает, что ему нужно в сообщении TSPEC – Traffic Specification) и делать выводы – разрешать клиенту подключаться, или игнорировать его. Так как данные механизмы разбросаны по ряду стандартов 802.11, была создана дополнительная сертификация WMM-AC (Admission Control), которая проверяет корректную их реализацию (а также, реализацию некоторых других вещей, обеспечивающих балансировку нагрузки во WLAN).
• Роуминг. Говоря о перемещающихся клиентах, важно помнить, что сам роуминг занимает некоторое время. В зависимости от настроек сети на инфраструктуре и клиенте это время может достигать нескольких секунд. Естественно, ни о каком качестве голоса тут речи идти не может, так как звонок просто разорвется. Для решения этой проблемы производители понапридумывали кучу классных, но проприетарных, механизмов, у которых были серьезные проблемы с совместимостью. Решить уже эти проблемы призван стандарт 802.11r (FT, Fast Transition), в котором детально описан механизм быстрого роуминга (<20ms). Однако, долгое время не существовало сертификации, подтверждающей корректную реализацию данного стандарта производителем. Это один из недочетов, которые Voice Enterprise призван исправить.
• Безопасность. Любая услуга должна быть безопасной. Единственной действующей сертификацией по безопасности Wi-Fi в настоящей момент является WPA2. Таким образом наше решение должно успешно работать в рамках данного механизма и ничего не ломать.
• Автономность. Все мы прекрасно знаем, насколько велика разница между «временем ожидания» мобильного телефона и «временем разговора», и на какие ухищрения идут производители мобилок (и сотовой инфраструктуры) для увеличения этого времени. То же самое происходит и в Wi-Fi. Здесь есть отдельная сертификация WMM-PS (Power Saving), оптимизирующая порядок обмена данными клиента с точками доступа для большей энергоэффективности.

Подведем итог. Даже просто для того, чтобы просто выбрать подходящие точки доступа и клиентские устройства для VoWLAN, необходимо проверить их на наличие пяти сертификаций (Wi-Fi, WMM, WMM-AC, WMM-PS, WPA2), а также на соответствие отдельным частям стандарта 802.11r, сертификации для которого просто нет. Кроме того, действительно быстрая работа 802.11r требует реализации некоторых функций из спецификаций 802.11k (RRM – Radio Resource Management) и 802.11v (WNM – Wireless Network Management), которые тоже нужно как-то проверить. Потом провести тесты на совместимость и надеяться на лучшее, так как ни одна из этих сертификаций и спецификаций не накладывает особых требований к самому алгоритму роуминга клиента («да, я поддерживаю 802.11r и могу роумиться быстро, но я буду роумиться только тогда, когда процент потерянных пакетов достигнет 80%»).

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

Таким образом, построение VoWLAN было делом рисковым, доверия к ним было мало, как следствие — низкая распространенность и востребованость. Описав масштаб бедствия, думаю, можно переходить к решению.

Решение

Решением призвана быть одна сертификация “Wi-Fi CERTIFIED Voice Enterprise” (именно в таком регистре), которая накладывает требования и на радиочасть, и на поддержку протоколов, и на совместимость, и на производительность и эффективность работы клиента в целом. Рассмотрим, что именно проверяется в сертификации:

• Корректность реализации протоколов. Обеспечивает совместимость.
  • RRM: части спецификации 802.11k. Обязательно для инфраструктуры и клиентов.
  • FT: части спецификации 802.11r. Обязательно для инфраструктуры и клиентов.
  • WNM: часть “BSS Transition Management” спецификации 802.11v. Опционально для инфраструктуры и клиентов. При наличии поддержки точка будет информировать клиента о своих соседях, позволяя тому заранее планировать, на какую точку роумиться дальше.
• Соответствие требованиям производительности. Обеспечивает качество. Тестируется по определенному набору сценариев, симулирующему различные ситуации в практически полностью загруженной сети. Обязательно для инфраструктуры и клиентов.
  • Задержка (включая части роуминга): <50ms в одну сторону
  • Джиттер: <50ms
  • Потеря пакетов: <1%
  • Последовательно потерянных пакетов: не более трех.
• Наличие других сертификаций. Для упрощения жизни.
  • Базовая сертификация: одна или несколько из сертификаций Wi-Fi (a/b/g/n). Обязательно для инфраструктуры и клиентов.
  • Безопасность: Voice Enterprise требует WPA2-Enterprise, что означает поддержку RADIUS и определенных типов EAP. Есть еще Voice Personal, там требования попроще.
  • QoS и управление полосой пропускания: WMM и WMM-AC соответственно. Обязательно для инфраструктуры и клиентов.
  • Энергоэффективность: WMM-PS. Обязательно для инфраструктуры, опционально для клиентов (к примеру, если клиент –микрокомпьютер с Wi-Fi закрепленный на автопогрузчике).

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

Почему-же «Ближайшее будущее»?

Итак, появилось решение довольно серьезной проблемы, позволяющее вывести VoWLAN из полуэкспериментальной фазы в мейнстрим, и доставить всем много профита хорошего. Решение важное и нужное. Почему же «Ближайшее будущее»?
Как и у двух других ключевых спецификаций Wi-Fi — 802.11i и 802.11n — выход Voice Enterprise регулярно переносился. Изначально планировалось запуститься в Ноябре 2007. Однако, в результате разнообразных пертурбаций официальный пресс-релиз о запуске сертификации и «скором начале тестирования и выдаче сертификатов» вышел только в Мае 2012. И даже сейчас, год спустя, на сайте WFA весьма сложно найти сертифицированные продукты. На самом деле, большинство вендоров Enterprise WLAN первого и второго эшелона уже давно поддерживают все необходимые технологии, но, похоже, не спешат с «официальной» сертификацией (возможно, ресурсы переброшены на борьбу за лидерство в 802.11ac, пока горячо). Так что, пока что Voice Enterprise для нас — «ближайшее будущее».
Но, думаю, в следующем году (или даже в конце этого) «официальная» поддерка Voice Enterprise будет заявлена для большинства точек доступа, и, что самое главное, для клиентских устройств, и это позволит голосу прописаться в беспроводных сетях настолько же прочно, как и в проводных.

Ваше мнение?

Среди масштабных планов улучшения Wi-Fi в ближайшей перспективе интересны три вещи:

• 802.11ac (он же «Гигабитный Wi-Fi») как средство повышения скорости и емкости WLAN
• Wi-Fi Certified Passpoint (он же Hotspot 2.0) на основе спецификации 802.11u, как способ значительно улучшить ситуацию с хотспотами и разгрузить сотовые сети.
• Wi-Fi Certified Voice Enterprise: как способ наведения порядка в ситуации с построением высокопроизводительных сетей для передачи голоса и видео. Отличную инфраструктуру можно построить и сейчас, но отсутствие жестких стандартов для клиентских устройств создает проблемы с работоспособностью решения в целом.

В этой части рассмотрим 802.11ac. Я уже писал обзор этой технологии в целом, так что сфокусируемся на прикладных аспектах. В целом, принятие 802.11ac как стандарта ожидается в начале 2014 года, что не помешало некоторым компаниям анонсировать чипсеты еще прошлым летом. На рынок технология будет выходить несколько этапов, названных "волнами".

• Wave 1 позволяет пробиться за гигабитный барьер «сырой» скорости передачи данных (~1300 теоретических Mbps при 3x3:3 MIMO с шириной канала 80MHz и новой модуляцией 256-QAM). В целом, тот же 802.11n, но быстрее.
• Wave 2 принесет дальнейшие улучшения в плане скорости (4x4:4 MIMO/160MHz ~= 3500Mbps) и емкости – MU-MIMO.
• Последующие волны могут принести остальные нововведения, считающиеся опциональными или слишком сложными для быстрого внедрения (типа 8x8:8 MIMO). А могут и не принести вообще - немало технологий описанных в стандарте 802.11n так и не были реализованы в реальных продуктах.

Продукты Wave 1 по состоянию на Май 2013 анонсированы уже достаточно большим количеством производителей как потребительского, так и бизнес-уровня: Aruba, Cisco, Motorola Solutions, Ubiquiti , ASUS, D-Link, Linksys, NetGear, TP-Link и все-все-все. Некоторые из них пока существуют только в стадии анонса, а некоторые уже можно и купить. Но стоит ли?

Давайте рассмотрим "за" и "против" этого "гигабитного Wi-Fi" и попытаемся понять.

Возросшая скорость передачи. Тут всё понятно – сеть быстрее, все как-бы рады. Только нужно помнить, что необходима поддержка на клиенте. Давайте посмотрим, что нужно для "пробития гигабитного барьера" на оборудовании Wave1. Обратимся к табличке скоростей из Wikipedia

• При ширине канала 20MHz, максимальная скорость на поток составляет ~87Mbps, что означает, что при нынешнем ограничении в 3 потока, гигабита нам не видать.
• При ширине канала 40MHz, максимальная скорость на поток составляет ~200Mbps, что означает, что при нынешнем ограничении в 3 потока, гигабита нам не видать. Зато, по сравнению с 802.11n мы ускорились на треть (600/450) просто путем замены железа.
• При ширине канала 80MHz, максимальная скорость на поток составляет ~433Mbps, что означает, что нам нужно задействовать все 3 потока. Это накладывает довольно строгие требования на план покрытия: нужно обеспечить 80MHz-каналы (неперекрывающиеся для соседних ячеек, так что нам нужно минимум 4, а где их найти?), плюс, нужно обеспечить благоприятную среду для трёх пространственных потоков, что не очень просто.

Даже с каналами 80MHz и правильным размещением точек, не стоит рассчитывать на гигабитные скорости. Большинство компактных клиентов не будет поддерживать три потока. Смартфоны обычно поддерживают 1 поток, планшеты – 1-2 потока, ноутбуки – 2-3 потока. Это важно помнить при планировании сети и не гнаться за скоростями, которые клиенты просто не смогут поддерживать. С Wave2 и MU-MIMO, однако, «малопоточные» клиенты будут обрабатываться гораздо эффективней. Скажем, точка с 4SS сможет параллельно вести передачу на 4 клиента с 1SS (по потоку на каждого) или на три клиента в комбинации 1+2+1 и т.д. Это должно значительно повысить эффективность использования эфирного времени и поднять емкость сети. Об этом ниже.

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

Немаловажным нюансом является также проводное подключение точек. Точка 802.11n может "выжать" максимум 900Mbps из двух радио (3x3:3/40Mhz), для чего вполне достаточно одного линка GE. Точка 802.11ac Wave 1 теоретически может выжать 2x1300Mbps = 2.6Gbps, для чего не хватит даже трех линков GE (а Wave2 так вообще все 7Gbps). Апгрейдить всё на 10GE? Будет довольно дорого. К счастью (как минимум для Wave 1) этого не нужно. Важно помнить, что пропускная способность Ethernet исторически меряется с учетом оверхеда самого протокола ("нетто"), а для Wi-Fi – без ("брутто"). Так что теоретические "сырые" 2600Mbps вполне реально втиснуть в 2 линка GE. Большинство объявленных точек 802.11ac Wave 1 имеют 2 порта GE и считается что этого хватит. Правда, придется доплатить за дополнительные порты на свитчах и прокладку второго кабеля (обычно ~50% от стоимости прокладки первого). Опять же, если мы строим сеть для BYOD (т.е. клиенты будут поддерживать 1-2 потока), то может хватить и одного гигабита.

Возросшая емкость сети. Полезным побочным эффектом возросшей скорости является то, что передача того же объема данных занимает меньше времени :) Таким образом, возрастает емкость нашей полудуплексной ячейки. Предположим, у нас есть некоторое количество клиентов 802.11n 1x1:1/40MHz (150Mbps) на точке доступа, каждому из которых требуется 10Mbps полосы пропускания. Для удобства вычислений положим, что эффективная пропускная способность ячейки составит 0.6 от теоретической = 90Mbps. При полудуплексном обмене, таким образом, ячейка сможет поддерживать 9 клиентов. При апгрейде на 802.11ac, сохраняя ширину канала и количество потоков, мы сможем получить теоретические 200Mbps в ячейке за счет 256-QAM, подняв емкость до 200*0.6/10 = 12 клиентов. Налицо прирост в 30% просто за счет замены железа. Если задуматься, кстати, емкость ячейки не зависит то того, будет ли у вас точка 2x2:2 или 3x3:3, т.к. при полудуплексной передаче для клиента 1x1:1 остальные потоки не используются. А вот с Wave2 и MU-MIMO в том же сценарии мы можем 12 клиентов легко превратить в 36 или 48. А при 8x8:8 - вообще в 96!

В принципе, вот и все основные факторы.

• С одной стороны: возросшая скорость и емкость
• С другой стороны: не всегда скорость достигается, требуется замена клиентов и точек (и те и те будут дороже), требуется апгрейд проводной части, всё купленное придется менять снова при выходе Wave2.

Сопоставив факторы, можно понять, когда переход на 802.11ac выгоден, а когда – нет.

Первый фактор – чисто экономический. Если возросшая скорость и емкость (которые мы научились прикидывать) действительно оправдывают дополнительную стоимость (которую мы тоже теперь можем оценить) – переход имеет смысл.

Второй фактор – стратегический. Покупать Wave1 сейчас или ждать Wave2 потом? Еще месяц назад сказал бы, что ждать Wave2, скорее всего не стоит, т.к. выход оборудования запланирован аж на 2015. Однако всего лишь на прошлой неделе был анонсирован чипсет Wave2 4x4:4 MU-MIMO!

Учитывая, после анонса первых чипсетов 802.11ac первые продукты Wave1 появились через ~полгода в потребительском секторе и менее чем через год в корпоративном – вполне возможно, что в это время в следующем году мы уже будем вовсю тестировать Wave2. Так что, если нет срочной потребности – стоит рассмотреть возможность перепрыгнуть сразу на Wave2.

Опять же, 4x4:4 MIMO еще понадобится запустить, а MU-MIMO имеет смысл только для относительно маломощных клиентов, да и апгрейд проводной инфраструктуры точно придется делать. Если хочется строить сеть для ноутбуков или делать беспроводной вынос прямо сейчас – Wave1 вполне подойдет.

Есть еще третий вариант. С выходом оборудования 802.11ac с текущего оборудования 802.11n слетит "налет новизны", а вместе с ним и наценка за крутизну. Таким образом, для тех, кто созрел апгрейдиться с 802.11a/b/g (или для тех, у кого сети вообще нет) вполне может подойти вариант недорого перейти на 802.11n, если производительность устраивает (склады, ритейл, хотспоты и т.д.). Для них гораздо более актуальными могут оказаться другие нововведения: Passpoint и Voice Enterprise, о которых поговорим в следующих частях.

Подборка забавных Hi-Tech шуток 2013. С изюминкой в конце поста.

Кликабельно.

Curiosity затроллили

Facebook монетизируется

Одиссея Google 9000

3D Printer для печати дешевой еды

Выигрывай с YouTube!

Обещанная изюминка. Есть что-то, что объединяет все эти шутки. Достаточно сообразительные найдут очень быстро и смогут закончить предложение в заголовке.

Я уже писал про необычные применения RFID: и про волшебное зеркало, и про выращивание мидий, и про ПРО на кораблях и другие интересности

С одной стороны, RFID потихоньку пробивает себе путь в широкие массы, вот уже и на ТВ сюжеты про "чудо-технологию" снимают (советую посмотреть сегмент про супермаркет "Перекресток" в Москве). С другой стороны, новые способы использования не перестают удивлять - буквально на этой неделе прочитал заметку об использовании RFID в ... в общем, смотрите сами.

Обоснование довольно простое - без использования RFID-сенсора в домах престарелых и больницах (где время от времени пациенты нуждаются в подобном уходе) "туда" по регламенту нужно заглядывать раз в четыре часа (каждому пациенту!). А с сенсором - автоматически приходит оповещение о необходимости замены конкретному пациенту. Значительно сокращаются затраты времени и нервов (персонала и пациентов) на "холостые" и запоздалые перемены исподнего.

Кто знает, может, лет через пять нечто подобное стационарно пропишется и обычных детских изделиях, и будет само писать в Твиттер родителям "Поменяй меня, пожалуйста!" :)

Field Tech Day — ежегодное мероприятие, где собираются вендоры и небольшое количество уважаемых блоггеров, и просиходит обмен информацией новинках. Отличительная черта мероприятия: подкованность аудитории (многие слушатели-блоггеры — собственно, инженеры, работающие в отрасли и знающие предмет разговора очень даже) и небольшое количество маркетинга (презентиции читаются инженерами вендором, на «чистых» маркетинг отводится минут 10 вступления). Плюс, часто всё это сопровождается практикой и т.д. В общем, весьма полезная штука для тех, кто хочет быть «в курсе».

На прошеднем на этой неделе Wireless TFD выступали (в порядке очередности):

• Motorola Solutions (впервые на TFD)
• Keith Parsons (если вы не слушали Wireless LAN Weekly — рекомендую)
• Juniper
• Aruba
• Cisco и Meraki (т.е. снова Cisco).

Не было таких «завсегдатаев» (если можно так сказать про мероприятие, которое до этого проводилось 3 раза) как Aerohive, MetaGeek, Ruckus.

Материалы выкладываются на Youtube и Vimeo, оглавление, подробности и ссылки — здесь. Пока что доступны материалы начальных дней. Думаю, на следующей неделе выложат всё остальное.
Интересующимся советую обратить внимание на список слушателей и поглядеть на их блоги!
P.S. Также на сайте TFD можно глянуть и на другие мероприятия: Networking TFD, Storage TFD, Virtualization TFD и «просто» TFD.