Текущая ситуация с Hotspot 2.0 в мобильном и фиксированном приложениях
Текущая ситуация с Hotspot 2.0 в мобильном и фиксированном приложениях
Для эффективного чтения статьи предполагается некоторое знакомство с мобильными сетями.
Мы давно не говорили об оффлоаде или выгрузке трафика мобильных данных из мобильных сетей в сети стандарта Wi-Fi. Но ситуация тем не менее продолжает развиваться. Такой оффлоад может быть, скажем так, чистым оффлоадом, использующим существующие современные сети Wi-Fi или оффлоадом с применением технологий Hotspot 2.0. В большей степени мы будем говорить о варианте с использованием именно HS2.0. Такой подход широко и горячо обсуждается сегодня в узких кругах. Более того, некоторые операторы уже что-то протестировали или даже в той или иной форме запустили коммерческие решения. Можно сказать, что вокруг HS2.0 разгорается пламя нового интереса после всплеска и падения в 2012-2013 годах из-за отсутствия совместимых устройств и механизмов провижининга. Тем более, что возможность использования HS2.0 - это привилегия далеко не только мобильных операторов или MVNO, им вполне могут пользоваться и все остальные фиксированные операторы и провайдеры.
Вероятно уже не имеет смысла обсуждать фундаментальные преимущества использования нелицензируемого или условно нелицензируемого спектра по сравнению с лицензируемым (фактически Wi-Fi против 3G/4G) для обслуживания огромного и постоянно растущего количества трафика данных, генерируемого разнообразными мобильными или иными нестационарными устройствами. Об этом много раз говорилось в самых разных статьях и на нашем ресурсе в частности. С другой стороны, без четкого понимания архитектуры целевого системного решения, особенностей и ассоциированным с этим решением бизнес-кейсом, многие преимущества могут быть существенно снижены из-за расходов, порой ненужных. Но обо всем по порядку.
Надо понимать, что Wi-Fi сеть может быть как доверенной, так и недоверенной по отношению к сети мобильного оператора связи. В этой статье мы будем говорить о варианте доверенной Wi-Fi сети (Trusted non-3GPP WiFi-Access, в соответствии с рекомендациями 3GPP). Недоверенный вариант подразумевает необходимость решения вопроса безопасности, что трансформируется обычно в формирование IPSec туннелей между клиентским устройством и мобильной пакетной корой. Это накладывает условия необходимости наличия специализированных клиентов на мобильном устройстве, а также устройств для терминации таких туннелей в коре, плюс весьма дорогие лицензии и т.п. Операторы обычно предпочитают работать с доверенным вариантом, который значительно проще и потенциально дешевле. В случае доверенной Wi-Fi сети эта сеть принадлежит либо самому мобильному оператору, либо его партнеру – фиксированному оператору связи, работающему в MVNO-модели по отношению к этому мобильному оператору. То есть, имеем сеть доступа стандарта Wi-Fi, полностью или условно контролируемую мобильным оператором. Естественно, что такой подход вызывает необходимость интегрировать сеть Wi-Fi с мобильной пакетной корой мобильного оператора связи. Или, в некоторых, пока редких, случаях, элементы мобильной пакетной коры покупает и разворачивает у себя фиксированный провайдер, который желает получить MVNO решение более глубокого уровня.
Для фиксированных операторов или провайдеров обычно нет необходимости так или иначе интегрироваться с мобильной сетью. Здесь более приоритетны устройства без мобильного радио, такие как разного рода настольные компьютеры и лаптопы, планшенты с Wi-Fi. Хотя, естественно, во многих случаях пользователи с самыми обычными мобильными смартфонами и планшетами, имеющими Wi-Fi радио, также будут стучаться в такую беспроводную сеть доступа, и мы должны быть к этому готовы.
Отсюда вытекают варианты клиентов, которых такая доверенная сеть Wi-Fi должна быть способна аутентифицировать и обслуживать:
1. Мобильные устройства с SIM-картой или USIM-картой, не поддерживающие HS2.0
2. Мобильные устройства с SIM-картой или USIM-картой, поддерживающие HS2.0 R1
3. Мобильные устройства с SIM-картой или USIM-картой, поддерживающие HS2.0 R2
(на начало 2016 г это перспективное направление)
4. Любые устройства без SIM-карты, не поддерживающие HS2.0,
5. Любые устройства без SIM-карты, поддерживающие HS2.0 R1,
6. Любые устройства без SIM-карты, поддерживающие HS2.0 R2
(на начало 2016 г это перспективное направление)
Диаграмма ниже отражает реальную качественную картину с клиентскими устройствами на рынке на момент выхода статьи.
Не-SIM устройства могут «принадлежать» как самому мобильному оператору связи, например, по контрактам с B2B-клиентами, так и быть клиентами фиксированного оператора, выполняющего роль MVNO в такой системе.
Затронув такую тему, как решения группы стандартов Hotspot 2.0, давайте вспомним что это, кто и чем там занимается и в чем смысл различных релизов.
Hotspot 2.0 был создан для решения главной проблемы: обеспечение Wi-Fi-пользователям такого же уровня простоты доступа к услуге в глобальном масштабе, как и пользователям мобильных сетей. Включил совместимое с HS2.0 устройство и магическим образом уже в Интернете. При этом пользователя не должно заботить, что происходит в сети. Все остальные интересные технологические возможности HS2.0 были добавлены именно к решению этой главной задачи.
В стандартизации технологий под общим названием Hotspot 2.0 участвуют в основном три организации:
1. IEEE.
IEEE занимается разработкой стандарта 802.11u. Поддержка этого стандарта обязательна как на стороне пользовательских устройств, так и на стороне сети Wi-Fi.
2. Wi-Fi Alliance (WFA).
Используя стандарт 802.11u как основу WFA работает над механизмами автоматизации поиска сети, аутентификации пользователей. Также WFA решает задачу совместимости пользовательских устройств и сети через обеспечение процедур совместного тестирования. WFA организовал и поддерживает программу сертификации Passpoint. Через эту программу уже прошли сотни устройств, совместимых с HS2.0 Release 1, и в настоящее время ведется работа по сертификации устройств и технологий для HS2.0 Release 2. Собственно Wi-Fi Alliance по большому счету и создает то, что в итоге принято называть Hotspot 2.0.
3. Wireless Broadband Alliance (WBA).
WBA разрабатывает требования совместимости технологий в коммерческих решениях используя наработки IEEE и WFA. WBA начал и продвигает очень важную инициативу, которая называется Next Generation Hotspot (NGH). NGH направлен на формирование механизмов глобального межсетевого роуминга для провайдеров услуг Wi-Fi-доступа. Здесь пока больше открытых вопросов, чем ответов, и процесс идет медленно. Фактически вариант межсетевого роуминга в осмысленной форме (функционально ограниченный) пока достигается путем стыка сети оператора с Wi-Fi-агрегатором, поддерживающим HS2.0. На сегодня такой функционал продемонстрировала компания Boingo. На момент выхода статьи у Boingo поддерживался сервис HS2.0для Apple iOS устройств, совместимых с HS2.0/R1. Также работает над похожим сервисом и другой крупный агрегатор iPass.
Много говорят о различных релизах Hotspot 2.0 в прессе. Давайте обсудим что это такое.
На начало 2016 года существуют два разработанных релиза Hotspot 2.0. Разработчикам пришлось пойти на такое деление, так как изначально поставленная задача оказалась крайне сложной в реализации.
1. Hotspot 2.0, Release-1.
R1 направлен на обеспечение автоматического доступа пользовательского устройства к сервису в хотспотах (сетях стандарта WiFi), где этот пользователь может быть аутентифицирован и авторизован. Путем использования 802.1x совместно с 802.11i архитектуры безопасности обеспечивается аутентификация на втором уровне и шифрование радиоканала в публичных хотспотах. Дополнительно возникла возможность обеспечивать интеграцию множества провайдеров-партнеров позади HS2.0 совместимой сети и предоставлять их пользователям автоматический доступ через единый HS2.0 совместимый идентификатор сети SSID. В R1 начал использоваться стандарт IEEE 802.11u, и был введен протокол поиска и обмена специализированными сообщениями ANQP (Access Network Query Protocol).
Несмотря на то, что на данный момент существует множество сетевых компонентов и пользовательских устройств, совместимых с HS2.0/R1, эти устройства пока не доминируют на рынке устройств. И, что самое главное, в R1 не был реализован интегрированный в системное решение провижининг пользовательских устройств. Таким образом, для построения сети HS2.0/R1 и использования совместимых пользовательских устройств придется решать вопрос управления конфигурациями.
2. Hotspot 2.0, Release-2.
R2 направлен на решение проблем с управлением пользовательскими устройствами и провижининга подписок. Для решения этой сложнейшей задачи была введена архитектура OMA-DM (Open Mobile Alliance’s Device Management), обеспечивающая использование древовидной структуры данных на базе XML. Также в R2 были введены новые сетевые элементы, главный из которых это OSU (Online SignUp сервер), призванный обеспечить безопасный провижининг и добавление устройств, поддерживающих R2, в сеть (onboarding).
Чтобы понять, чем отличаются процедуры доступа HS2.0 устройства в сеть WiFi/HS2.0 от любого обычного Wi-Fi устройства (не HS2.0) в обычную сеть Wi-Fi, давайте рассмотрим без погружения в детали то, как происходит взаимодействие в сети HS2.0.
Итак доступ в сеть с поддержкой HS2.0:
• Точка доступа Wi-Fi отправляет биконы, в которых содержатся дополнительные поля в соответствии со стандартом 802.11u. Пользовательские устройства, понимающие 802.11u, слушают такие биконы.
• Пользовательские устройства отправляют пробы с полями 802.11u.
• Устройство выбирает точку доступа и направляет ANQP запрос с требованием предоставить HS2.0 информацию. Это может быть, например:
-название локации (название магазина, стадиона и т.п.),
-IP-адресация,
-идентификатор сети (NAI Realm),
-лист DNS,
-метрики внешнего канала передачи данных (WAN).
• Точка доступа отвечает с помощью ANQP предоставляя информацию.
Это может быть, например:
-SuperShoppingMall
-IPv4 NAT
-MNO-aaabbb.com / TTLS
-MCC yyy MNC zzz
-MNO.com
-12/3 Mbps, Up/Up
• Устройство сравнивает предварительно сконфигурированый профиль у себя с данными, полученными от точки доступа, и выполняет ассоциацию к нужному SSID, если это возможно.
Все описанное, если пользовательское устройство поддерживает HS2.0 и уже было отпровиженено для этого своим домашними оператором связи, происходит автоматически. Сеть, где пользователь хочет получить доступ, должна поддерживать роуминговые отношения с его домашним оператором. Это может быть достигнуто через прямую межоператорскую интеграцию, либо через выход на специализированные HS2.0 совместимые точки обмена трафиком. Либо это может быть стык с совместимым Wi-Fi-агрегатором, например, таким как уже упомянутый ранее Boingo. Если все выстроено как надо, то пользователю достаточно просто захотеть воспользоваться этим доступом - и вперед в Интернет. При правильном развитии событий, если устройство поддерживает HS2.0 и 802.1х, нет необходимости искать нужную сеть, вводить логин/пароль и т.п.. Вот тогда у пользователя и возникает ощущение того самого почти магического доступа в Интернет через Wi-Fi также как в обычную мобильную сеть для звонков.
Теперь давайте остановимся на том, какие варианты оффолоада существуют и чем они отличаются. Названия достаточно условные, но отражающие суть вопроса.
1. Простой или обычный оффлоад.
2. Оффлоад с использованием Hotspot 2.0
Простой оффлоад подразумевает возможность для бОльшей части современных устройств получить доступ в сеть Wi-Fi. При этом именно для возможности оффлоада трафика мобильных данных мобильные устройства должны обладать поддержкой одного из следующих методов аутентификации характерных для мобильных устройств: EAP-SIM, EAP-USIM, EAP-AKA. Обычно сегодня используется EAP-SIM. Учитывая тот факт, что клиентская информация в таком случае хранится в HLR (Home Local Register) или HSS (Home Subscription Server) мобильного оператора связи, то сеть Wi-Fi должна быть интегрирована через RADIUS-протокол с мобильной корой. Кстати, стОит сказать, что в некоторых ситуациях HLR может быть частью HSS-структуры, но это редкость. Отметим, что HLR не поддерживает RADIUS-протокол, а методы EAP передаются в RADIUS-сообщениях, поэтому типичная практика состоит в конвертировании EAP-SIM в SIGTRAN для взаимодействия с HLR. В случае достаточно старых HLR, которые не поддерживают SIGTRAN, а только SS7 по цифровым потокам типа E1/T1 или большего уровня, может применяться STP (Signaling Transfer Point). В зависимости от вендора, часто такой элемент не только способен терминировать RADIUS c EAP-SIM, но и конвертировать EAP-SIM в SS7 и передавать через TDM-каналы. В IP-сети функцию конвертирования EAP-SIM в SIGTRAN выполняет чаще всего AAA-Сервер с функционалом MAP-конвертера или МАР-шлюза. Для не-SIM клиентов очень популярны методы EAP-TLS, EAP-TTLS, PEAP в рамках 802.1x архитектуры безопасности.
Если же допускается наличие клиентов, не поддерживающих 802.1х, то может быть задействована web-аутентификация через веб-портал. Надо отметить, что web-порталы стремительно теряют популярность в силу низкого уровня безопасности у такого подхода. В некоторых ситуациях web-порталы начинают использоваться для провижининга (внесения изменения в конфигурацию) устройств. В данном случае на портале может быть расположен профиль для внесения изменений в конфигурацию устройства для, например, начала пользования своими Hotspot 2.0 функциями. Пользователь может скачать такой профиль, применить и далее все будет происходить автоматически. Так сегодня конфигурируются Apple iOS устройства, поддерживающие HS2.0/R1 и совсем недавно схожая поддержка была добавлена в Android 6.
Если операторская сеть Wi-Fi построена по централизованной архитектуре, управляемой контроллером беспроводной сети, то такой контроллер обычно выполняет функцию прокси-сервера, например, для RADIUS-протокола, перенаправляя RADIUS сообщения на внешний ААА-Сервер или для HTTP/HTTPS-протокола, выполняя редирект (перенаправление) таких сообщений на внешний веб-портал. Даже если контроллер WLAN имеет встроенный веб-портал и какие-либо возможности аутентификации, то использование внешних устройств делается для масштабирования решения и получения значительно более обширного ААА функционала и многих других преимуществ.
Контроллер WLAN, помимо собственно комплексной функции управления сетью Wi-Fi, может выполнять и функцию WAG (Wireless Access Gateway, 3GPP). Либо WAG может быть отдельным устройством, работающим совместно с контроллером в едином решении. Если не углубляться в не слишком важные на данном этапе детали, то основная задача WAG это объединение мира WiFi c мобильным миром путем формирования различных туннелей и, прежде всего, GTP-туннелей (GTP: GPRS Tunneling Protocol). Соединение по GTP в общем случае выполняется одним из следующих способов:
1. Интеграция WAG и 3G GGSN путем использования GTPv1,
2. Интеграция WAG и 4G PGW путем использования GTPv2.
Дабы не усложнять, оставим описание интерфейсов за скопом данной статьи. Вы всегда можете найти эти подробности в соответствующих документах 3GPP.
Теперь давайте вернемся к использованию GTP-протокола для интеграции сети Wi-Fi c мобильной пакетной корой. Этот подход, с одной стороной, рекомендован 3GPP, но насколько это оправдано для операторов связи, участвующих в проекте, особенно для мобильного оператора? Давайте разбираться.
Мобильное устройство в мобильной сети передает данные через так называемый PS-домен (packet switched) или домен с коммутацией пакетов. При этом передача голосового трафика идет через CS-домен (circuit switched) или домен с коммутацией каналов. Теоретически сети четвертого поколения (LTE/Advanced-LTE) могут поддерживать и голос, и данные поверх IP, тем самым трансформируясь в All-IP сети, но таких гомогенных сетей с масштабной поддержкой голоса и данных по IP на момент выхода статьи в мире, можно считать, практически нет. Мобильные сети, даже самые современные, являются гетерогенными, объединяя в себе и наследие прошлых лет и современные технологии. И с этим приходится жить в реальном мире. Отсюда вытекают крайние сложности в реализации хендоверов с сохранением сессии из доступа одной технологии (например, 3G) в доступ другой технологии (например, Wi-Fi) и наоборот. И намного все сложнее с голосовыми сессиям, особенно если такая сессия была инициирована в cs-домене мобильной сети и надо ее продолжить в сети Wi-Fi, которая по определению пакетная или наоборот. Надо сказать, что некоторые варианты решения проблемы существуют, но ни один пока не получил массово признанного распространения. В целом, это большой и сложный вопрос, который не является темой данной статьи.
Важно знать, что очень многие сегодняшние мобильные устройства, если не все, после присоединения к сети Wi-Fi и начала оффлоада трафика данных в эту сеть, продолжают поддерживать свой GTP-туннель в мобильную пакетную кору через мобильную сеть. Дополнительно к этому обязательно возникает еще один GTP-туннель от WAG в пакетную кору на сессию этого же абонента. Таким образом, для реализации оффлоада мобильных данных в Wi-Fi с интеграцией через GTP-туннели часто надо существенно наращивать количество лицензий и производительность мобильной пакетной коры (GGSN и/или PGW). То есть, в первом приближении очень грубо можно говорить о необходимости удвоения количества лицензий в коре. Конечно, это можно и нужно аккуратно оптимизировать, но для простоты восприятия примем допущение об удвоении. Отсюда для большой абонентской базы мобильного оператора только модификация пакетной коры может добавить в проект миллионы, если не десятки миллионов долларов. И это не считая собственно развертывания самой сети Wi-Fi и шлюзов WAG.
Ряд мобильных операторов однозначно предпочитают получать трафик данных вне зависимости от типа доступа в свою пакетную кору, чтобы применять единый механизм полисинга, расчета трафика и биллингации ко всем абонентам. Это понятное желание, но его реализация в итоге становится очень дорогой на практике.
Помимо GTP-туннелей для интеграции могут быть использованы и другие туннельные технологии, например, PMIPv6, SoftGRE и ряд других, менее популярных. Но GTP остается самым распространенным и понятным на сегодня вариантом для мобильных операторов связи.
Что же можно сделать, чтобы снизить затраты на построение решения для оффлоада? В любом случае для оффлоада мобильных данных придется выполнять интеграцию как минимум для обеспечения аутентификации абонентов. Пожалуй, один из самых интересных (и финансово значимых) вопросов при этом – а надо ли выполнять интеграцию с мобильной пакетной корой через те или иные туннельные технологии? При определенных условиях этого не избежать, например, при однозначном требовании сохранения непрерывности сессий. Но такое условие накладывает массу дополнительных требований, как, например, введение функции Home Agent и т.п. Другая ситуация возникает, когда мобильный оператор хочет весь трафик данных, вне зависимости от типа доступа, направлять в свое пакетное ядро. Мотивацию мы обсуждали ранее. Такое желание понятно и очевидно, но цена воплощения очень высока, как мы уже посмотрели выше: удвоение количества лицензий в пакетной коре.
А надо ли туннелировать трафик в мобильную пакетную кору, если никаких специальных условий нет? Контрольную часть трафика (Control plane), прежде всего RADIUS-сообщения, придется в любом передавать из сети Wi-Fi в мобильное ядро для выполнения аутентификации абонентов, как было описано ранее. Но трафик данных (Data plane) перенаправлять в ядро совсем не обязательно. Его можно вполне терминировать локально, прямо на точках доступа, и перенаправлять по ближайшему маршруту в Интернет. Это называется Local Breakout. Если оператор имеет полнофункциональный 3GPP ААА-сервер, то с помощью него можно не только проводить аутентификацию абонентов, но и выполнять аккаунтинг для расчета трафика и биллингации. При этом такой ААА-сервер, как правило, умеет выполнять конверсию RADIUS в SIGTRAN. Если такой ААА-сервер уже существует у оператора, то его расширение обычно не требует затрат хоть сколько-нибудь соизмеримых с расширением GGSN или PGW.
В качестве примера, некоторые крупные мобильные операторы даже провели вполне успешное тестирование оффлоада и Hotspot 2.0 с интеграцией через GTP, а после этого внимательно посчитали полные затраты и поняли, что оффлоад нужен, но надо оптимизировать затраты. В итоге оффлоад и Hotspot 2.0 остались, но при переходе к коммерческой эксплуатации от туннелей в ядро отказались, выполняя локальную терминацию трафика данных. Это позволило снизить затраты до приемлемого уровня и при этом успешно выполнить поставленную задачу.
Если идти по упрощенному пути, то для развертывания решения с Hotspot 2.0, которое будет способно работать как с HS2.0-, так и с не-HS2.0 клиентами, потребуется в общем случае:
1. Точки доступа Wi-Fi, поддерживающие HS2.0 (802.11u).
2. Контроллер сети Wi-Fi, поддерживающий HS2.0.
3. AAA-сервер для аутентификации и аккаунтинга своих пользователей и интеграции с другими сетями через RADIUS-прокси механизм. Для интеграции с мобильной пакетной корой на ААА-сервере потребуется функционал МАР-шлюза.
4. Средства безопасного введения новых клиентов в сеть (onboarding).
Также придется решать вопросы интеграции с другими операторскими сетями или агрегаторами.
Короткий формат статьи не может охватить все нюансы и подводные камни на непростом пути реализации решений HS2.0, но мы попытались затронуть основные аспекты и особенности.
Не пропускайте новости Wi-Fi, которые мы публикуем в Новостной Ленте.
Для получения анонсов по выходу новых статей или при появлении новых материалов на нашем сайте подписывайтесь на рассылку.
Присоединяйтесь к нашей группе на Facebook: www.facebook.com/Kom.Way.ru
Мы публикуем интересные новости о Wi-Fi со всего света, информацию о выходе новых статей и расширении контента основных модулей ресурса komway.ru
Kom-Way.Team
Использование материалов сайта komway.ru разрешено только с согласия komway.ru и при наличии прямой ссылки на komway.ru.
