Архитектура оффлоада трафика мобильных данных через сети Wi-Fi
Архитектура оффлоада трафика мобильных данных через сети стандарта Wi-Fi
Перевод статьи о решении Cisco SP WiFi/Service Provider Wi-Fi
Введение
Трафик данных мобильных сетей растет экспоненциально, и провайдеры услуг должны эффективно управлять своими сетями, чтобы отвечать требованиям пользователей. Возможности эволюции сетей радиодоступа ограничены законами физики, и какого-то резкого прироста эффективности использования радиоспектра уже не стоит ожидать. Сети радиодоступа на основе стандарта 3GPP LTE (Long-Term Evolution) подошли к пределам закона Шенона, спектр, доступный для передачи мобильных данных, является ограниченным и единственным действенным решением увеличения общей емкости радиосети. Подход состоит в уменьшении размера ячеек и развертывании технологий малых сот.
Наиболее эффективный путь использования малых сот состоит в размещении их в зонах, где генерируются значительные объемы трафика данных (торговые центры, стадионы, университетские кампусы, вокзалы городского транспорта и тп), и там, где пользователи проводят большую часть их времени и потребляют большое количество трафика (дома, в офисе и тп).
Wi-Fi, как одна из технологий малых сот, выглядит для многих операторов эффективной по затратам для оффлоада огромных объемов трафика мобильных данных с возможностью предоставления большого количества новых услуг. Технология несет следующие возможности:
- Широкая распространенность сетей стандарта WiFi 802.11 (подробнее о сетях стандарта WiFi),
- Доступность пользовательских устройств с поддержкой стандарта Wi-Fi,
- Эффективность по затратам (подробнее о бизнес-эффективности WiFi-решений),
- Возможности предоставления сервиса новым пользователям и устройствам без мобильной подписки (без необходимости использования SIM-карты),
- Глобально доступные частоты WiFi (подробнее о частотах WiFi),
- Наличие стандартов для интеграции сетей Wi-Fi 802.11 в пакетную корневую часть мобильных сетей.
Данный документ рассматривает технические аспекты архитектуры для WiFi-оффлоада (WiFi offload) и возможности по интеграции с существующими мобильными сетями для обеспечения эффективного способа выгрузки трафика данных мобильных абонентов.
Обзор архитектуры WiFi-оффлоада
Стандарты 3GPP (The Third-Generation Partnership Project) разделяют два типа WiFi-доступа, также известного как не-3GPP IP-доступ:
- Недоверенный доступ стандарта WiFi:
Данный тип доступа был введен на ранних стадиях работы над спецификациями Wi-Fi в 3GPP Release 6 (2005 год). Недоверенный доступ включает любой тип доступа/устройства Wi-Fi, который не контролируется оператором (публичный открытый хотспот, домашний Wi-Fi маршрутизатор абонента и тп) или варианты с недостаточным уровнем безопасности (аутентификации, шифрования и тп).
- Доверенный доступ стандарта WiFi:
Данный типа доступа относится к сетям стандарта Wi-Fi, которые построены самим оператором с обязательным шифрованием радиоканала и использованием сильных методов аутентификации. Доверенный не-3GPP IP-доступ был введен начиная с выхода LTE в 3GPP Release 8 (2008 год). Хотя большинство современных дизайнов WiFi оффлоада основаны на доверенной модели, 3GPP в настоящее время не предлагает рекомендаций по интеграции с пакетным ядром 3G и 2G сетей. Однако, как будет представлено в документе, такой тип доступа интегрирован в пакетное ядро сети LTE EPC(Evolved Packet Core).
Большинство сегодняшних мобильных сетей основаны на 3G и существенная часть данного документа описывает возможные методы интерграции доверенных не-3GPP IP-сетей доступа в мобильное пакетное ядро 3G (MPC/Mobile Packet Core) вместе с необходимыми архитектурными компонентами полисинга и тарификации (PCC/Policy & Charging Control). Хотя термин "доверенный не-3GPP IP-доступ" определен только для LTE EPC, данный документ расширяет это определение с учетом 3G контекста для того, чтобы описать WiFi-сети, контролируемые мобильными операторами.
Документ 3GPP 24.302 имеет следующее определение: "Для доверенной не-3GPP сети IP-доступа коммуникации между оборудованием пользователя и пакетным ядром сети EPC являются безопасными". Это определение дается с учетом применения современной SP Wi-Fi архитектуры, использующей EAP (Extensible Authentication Protocol) и IEEE 802.1x аутентификацию, а также шифрование радиоканала с помощью IEEE 802.11i и опционального использования DTLS (Datagram Transport Layer Security) для обеспечения безопасности каналов обмена контрольной информации и пользовательских данных. Все описанные компоненты существуют в решениях SP Wi-Fi, и с их использованием такие сети могут рассматриваться, как доверенные не-3GPP.
Данный документ сначала рассматривает 3GPP дизайны, а затем описывает эволюцию таких архитектур к интеграции в EPC, как определено в 3GPP-стандартах.
В спецификациях 3GPP сеть Wi-Fi рассматривается только как сеть WiFi-доступа. Никаких деталей о структуре сети Wi-Fi не специфицируется. Данный документ разделяет сеть Wi-Fi на компоненты доступа и шлюза. Сеть Wi-Fi для оффлоада мобильных данных состоит из трех частей:
1. сеть радиодоступа WiFi-стандарта (Wi-Fi RAN)
2. шлюз доступа Wi-Fi (WAG/ WiFi Access Gateway) и необходимые вспомогательные системы
(документ также расширяет определение 3GPP TS 23.234 для введения не-3GPP WAG)
3. Элементы интеграции в пакетное ядро мобильной сети
Рисунок 1
Архитектура сети Wi-Fi. Показана интеграция как элеметов 3G, так и LTE, чтобы продемонстрировать общую картину всех сценариев, представленных в данном документе.
Если сеть Wi-Fi используется для оффлоада трафика мобильных данных, то необходимо решить следующие задачи:
1. Аутентификация: чтобы гарантировать, что только авторизованные пользователи могут получить доступ к сети,
2. РСС: для обеспечения корректной биллингации, качества обслуживания (QoS) и применения политик к трафику, который генерируется в сети доступа Wi-Fi. В идеале это должно полностью соответствовать 3GPP PCC,
3. Непрерывность IP-сессии: для обеспечения бесперебойности предоставления услуг при движении между различными сетями доступа (3G>Wi-Fi, Wi-Fi>3G, между точками доступа внутри сети Wi-Fi).
Итак.
Аутентификация
Для контроля доступа пользователей к сети стандарта Wi-Fi может быть использовано множество методов аутентификации. Выбор метода аутентификации является критичным для удобства использования в сети (и для обеспечения необходимого уровня безопасности, прим. komway.ru). Чем проще и прозрачнее метод аутентификации для конечного пользователя, тем больше вероятность того, что пользователь присоединится к сети.
Метод аутентификации также определяет пользователя и тип пользовательского устройства, которые могут быть использованы в конкретной сети (пользователи с SIM-картой или без таковой, собственные абоненты мобильного оператора, пользователи-гости в данной сети и тп).
В обычной современной сети Wi-Fi доступны в среднем два типа аутентификации, чтобы обеспечить возможность доступа всех возможных потенциальных пользователей с необходимым уровнем удобства при доступе для частых пользователей услуги Wi-Fi. Первый метод- это аутентифкация через веб-портал, что дает возможность доступа для пользователей, не имеющих постоянного контракта с оператором (ваучеры, доступ с ограничением по времени, платеж через SMS и тп). Второй типовой метод- это аутентификация с помощью EAP, которая обеспечивает прозрачный доступ к услуге и простой доступ для собственных абонентов мобильного оператора с SIM-картами или сертификатами.
Аутентифкация через Веб-портал
Веб-аутентификация построена на взаимодействии третьего уровня (L3 OSI/ISO) с сетью и использует HTTP до того, как разрешить доступ пользователю. WISPr стандарт (Wireless Internet Service Provider) также использует HTTP-коммуникации с веб-порталом для автоматической аутентификации с пользовательским устройством без какого-либо вовлечения пользователя, см рисунок 2.
Рисунок 2
Архитектура аутентификации с помощью веб-портала
Данный метод использует WAG в сети Wi-Fi, который блокирует все IP-коммуникации для неизвестных (новых) пользователей и перенаправляет все HTTP-сессии на перехватывающий веб-портал. Перехватывающий веб-портал отвечает за запрос уникальной информации по доступу у пользователя (логин/пароль и тп) и инициирует фазы аутентификации, авторизации и аккаунтинга (ААА) для аутентифкации пользователя. После успешного логина WAG извещается об этом ААА-сервером. С этого момента пользователь известен и находится в ААА-кэше, и WAG разрешает этому пользователю отправлять и получать данные. Обычно IEEE 802.11 MAC-адрес пользователя (например, МАС смартфона пользователя) также закэширован на ААА-сервере вместе с данными пользовательской аутентификации и разрешенного сервисного профиля пользователя. Если пользователь покидает зону покрытия Wi-Fi и затем возвращается, пользовательское устройство будет распознано шлюзом WAG по МАС-адресу и автоматически аутентифицировано по закешированной записи на ААА. Поэтому пользователю не надо постоянно заходить на веб-портал и повторно выполнять аутентифкацию после потери сети Wi-Fi. Этот метод кеширования МАС-адреса также называется TAL (Transparent Automatic Logon), см рис. 3, WAG присоединяется на втором уровне.
Рисунок 3
Типовая последовательность шагов при TAL
EAP-аутентифкация
EAP-аутентификация использует EAP и IEEE 802.1x для аутентифкации пользователей на втором уровне (L2 OSI/ISO), которые входят в сеть с устройствами, поддерживающими ЕАР. В данном случае для аутентификации может использоваться большое количество способов в зависимости от возможностей устройства.
Устройства с SIM-картой используют данные SIM для информационного обмена внутри сообщений EAP, и эта информация проксируется ААА-сервером к домашнему HLR (Home Location Register) мобильного оператора пользователя для фактической аутентифкации. В таком случае используются методы EAP-SIM (RFC 4186) и EAP-AKA (RFC 4187) для энкапсуляции данных в зависимости от типа SIM-карты и возможностей HLR. Очевидно, такой подход требует обеспечения соединения между ААА-сервером и HLR или HSS (Home Subscriber Server), см рис. 4.
Рисунок 4.
Архитектура ЕАР-аутентификации
Для пользователей с устройствами без SIM-карты оператор может использовать специальные сертификаты для EAP-TLS (Transport Layer Security) или для иных схожих методов.
Последовательность шагов при ЕАР-аутентифкации (с интегрированным HLR) представлена на рис 5.
Рисунок 5.
Типовая последовательность шагов при ЕАР-аутентифкации
Помните, что аутентификация на основе EAP дает значительные преимущества в части безопасности радиоканала. В данном случае аутентификация выполняется на втором уровне и сообщения EAP могут использоваться для согласования ключей шифрования радиопередачи по стандарту 802.11i. Такой подход обеспечивает более высокий уровень безопасности беспроводных коммуникаций в сравнении с незашифрованным радиообменом в случае аутентификации через веб-портал, а также обеспечивает предотвращение простых атак по спуфингу МАС-адресов.
Хотспот стандарта WiFi следующего поколения (Hotspot 2.0)
В 2010 году Cisco и другие лидеры индустрии сформировали специальную группу по разработке стандартов для Хотспотов следующего поколения (Next Generation Hotspot Task Group) в организации WBA (Wireless Broadband Alliance). Целью стало направить индустрию по пути создания общей группы стандартов, названных Hotspot 2.0, и которые смогли бы обеспечить пользователю опыт, схожий с использованием сетей 3G, а также сформировать модель межсетевого WiFi-роуминга. Результатом работы данной группы стали рекомендации операторам связи и программа сертификации Passpoint (Wi-Fi Certified Passpoint), стартовавшая летом 2012 года в WiFi Alliance. Эта программа сертификации как сетевого, так и пользовательского Wi-Fi оборудования, сможет гарантировать интероперабельность по аутентификации и роумингу для операторов и производителей оборудования.
SP Wi-Fi решение от Cisco c функционалом NG Hotspot дает возможность операторам лучше управлять и монетизировать их WiFi-сети операторского класса.
Можно выделить три основных составляющих архитектуры сети для Хотспотов стандарта WiFi следующего поколения:
1. IEEE 802.11u,
2. Wi-Fi Protected Access 2 (WPA 2) Enterprise,
3. EAP-аутентификация.
Краткое резюме по аутентификации в сетях WiFi
Учитывая дополняющие возможности обоих описанных методов аутентификации, мобильные операторы, которые разворачивают сети доступа стандарта Wi-Fi, обычно используют как EAP и 802.1x аутентификацию, так и аутентификацию через веб-портал в своих сетях.
Аутентифкация через веб-портал используется для привлечения гостевых пользователей по отношению к данной сети и тех, которые не имеют отношений с данным оператором связи. Такая схема дает возможность использования обычных распространенных приложений, как, например, платежи с помощью пластиковых карт, ваучеры и смс-пароли. Это приносит дополнительный доход от Wi-Fi сетей.
EAP-аутентификация в основном нацелена на устройства с SIM-картой оператора. Данная модель обеспечивает прозрачную аутентификацию и безопасные коммуникации без больших усилий со стороны пользователя (только в первый раз необходимо выбрать или настроить идентификатор правильной сети WiFi-стандарта и далее данный профиль будет использоваться устройством автоматически). В реальной жизни использование EAP-SIM и EAP-AKA методов ведет к значительно более высокому уровню использования сети Wi-Fi пользователями и таким образом обеспечивает значительно более высокие уровни экономии на выводе трафика данных из мобильной сети в Wi-Fi (оффлоад) для мобильного оператора.
С появлением пользовательских устройств, сертифицированных по Passpoint, операторы смогут упростить доступ в сеть Wi-Fi еще более значительно. Устройствам с поддержкой стандарта IEEE 802.11u не нужны никакие воздействия со стороны пользователя для присоединения к сети Wi-Fi (в отличие от обычных устройств, где необходимо выбирать SSID и тп). Межоператорские роуминговые соглашения на базе рекомендаций NG Hotspot (WRIX/WLAN Roaming Inter-Exchange)) дают возможность устройству с 802.11u выбрать правильный SSID автоматически, даже если пользователь находится в чужой сети (но имеющей роуминговое соглашение с домашним оператором пользователя и также поддерживающей 802.11u, прим. komway.ru).
Выделенный элементы PCEF
(Policy and Charging Enforcement Function)
В сценарии использования выделенного PCEF шлюз WAG настраивается для отправки пользовательского трафика данных к PCEF для интеграции с PCC. В то же время трафику, который не требует контроля по политикам (трафик гостевых пользователей, трафик в схеме перепродажи, трафик пользователей с одноразовыми ваучерами и тп), может предоставляться прямой маршрут в Интернет, см. рис 6.
Рисунок 6
Архитектура с выделенным PCEF
Учитывая, что для PCEF необходимо уметь находить соответствие между идентификатором пользователя и соответствующим потоком данных, проходящим через PCEF, то возникает требование наличия механизма, который бы синхронизировал идентификатора пользователя с IP-адресом подписчика (так, чтобы отдельные пакеты данных могли быть ассоциированы с конкретным потоком данных пользователя и могли обрабатываться в соответствии с этим). Обычно функция проксирования RADIUS-сообщений используется на PCEF для создания информационной базы пользовательских сессий, основываясь на атрибутах, включенных в сообщения аккаунтинга, приходящие от шлюза доступа по конкретному пользователю, см рис 7.
Рисунок 7.
Обмен сообщениями при аутентификации на PCEF.
Если используется данная модель, то необходимо гарантировать оператору, что вся обязательная информация, необходимая для PCEF, включена в RADIUS-сообщения от шлюза доступа или проксируется через ААА-сервер, где уже необходимые атрибуты добавляются в сообщение. В дополнение к IP-адресу пользовательской сессии обычно требуются:
- IMSI (International Mobile Subscriber Identity)
- MSISDN (Mobile Station International Subscriber Directory Number)
- APN (Access Point Name).
Туннели GTP в сторону традиционного GGSN
Если PCEF является интегральной частью GGSN, тогда опция перекладки WiFi-сессий в GTP-туннели (пакетный протокол передачи данных, PDP-контекст) может предложить наилучшее решение для интеграции PCC. В данном случае трафик, который не принадлежит мобильным абонентам оператора и который, таким образом, не может быть обработан на GGSN, перенаправляется напрямую в Интернет, см. рис 8.
Рисунок 8.
Архитектура GTP-к-Традиционному GGSN.
Данная модель решения однозначно требует поддержки GTP на WAG. Важно также обеспечить доступность требуемых атрибутов в запросе PDP-контекста, которые обязательны для PCC-системы оператора. Как уже говорилось ранее, эти атрибуты обычно включают IMSI, MSISDN, профиль QoS, APN, см рис 9.
Рисунок 9.
Последовательность шагов в модели GTP-к-Традиционному GGSN.
Важно понимать, что даже несмотря на то, что все сессии (3G и Wi-Fi) контролируются на GGSN, данное решение не поддерживает прозрачный хендовер IP-сессий между Wi-Fi и 3G радиосетями. Это происходит из-за того, что Wi-Fi и 3G контексты PDP являются индивидуальными сессиями и пользователькое устройство может открыть их одновременно. К сожалению, стандарт 3GPP не предлагает механизма, который бы гарантировал, что один и тот же GGSN выбран для обоих контекстов PDP.
PCC Интеграция
При выполнении PCC интеграции необходимо понимать следующее:
1. Описанные опции применимы и необходимы для 3G. Позже будет показано, что LTE предоставляет интеграцию в EPC и, таким образом, в PCC,
2. Критически важно, чтобы WAG мог предоставлять всю необходимую информацию для тарификации (это особенно важно с учетом того, что некоторые из требуемых атрибутов не являются частью EAP-аутентификации и их необходимо получать отдельно, если необходимо, например, MSISDN, профиль QoS и, опционально, характеристики тарификации 3GPP),
3. Обычно PCEF не обслуживает трафик пользователей, которые не являются мобильными абонентами оператора (не-SIM абоненты). Такой трафик отправляется напрямую в Интернет. Если таким сессиям необходим полисинг и применение функций тарификации, то это обычно выполняется на WAG и системах обеспечения сети Wi-Fi.
LTE
До того как будет представлена третья функция архитектуры WiFi-оффлоада - хендовер сессии, будет показан сценарий интеграции PCC в LTE. Это позволит позже разобраться с мобильностью пользовательских сессий и их центрального контроля и терминации.
3GPP TS 23.402 описывает интеграцию доверенной и недоверенной не-3GPP сетей IP-доступа с EPC. Стандарт допускает, что сеть стандарта Wi-Fi является допустимой сетью доступа, как любая другая сеть доступа на базе 3GPP. Это позволяет операторам использовать стандартные компоненты EPC для интеграции и, таким образом, помогает гарантировать хороший уровень интероперабильности между различными типами доступа.
Как упоминалось ранее, документ концентрируется на доверенной части архитектуры. Для отправки трафика Wi-Fi к EPC определены два интерфейса, и оба терминируют сессии Wi-Fi на шлюзе пакетных данных (P-GW/Packet Gateway), см рис 10.
Рисунок 10.
3GPP-архитектура для интеграции не-3GPP IP-доступа с EPC. Опция S2c.
Интерфейс S2c основан на двухстековом мобильном IPv6 протоколе (DSMIPv6/Dual-Stack Mobile IPv6) и требует специальной поддержки на стороне оборудования пользователя. DSMIPv6 создает туннельное соединение между пользовательским устройством и P-GW, который используется для пересылки всего трафика к- и от устройства пользователя. P-GW отвечает за назначение виртуальных IP-адресов для туннеля в процессе его установки. Этот IP-адрес из того же IP-пула, который используется для LTE-сессий. Учитывая, что весь трафик к-/от пользовательскому устройству отправляется через туннель, то P-GW имеет полную картину трафика пользователя и может применять функции PCC или другие требуемые функции идентично тому, как это делается с сессиями LTE, см. рис 11.
Рисунок 11.
3GPP-архитектура для интеграции не-3GPP IP-доступа с EPC. Опция S2a.
Другая опция, показанная на рисунке 11, говорит о выборе интерфейса S2a для пересылки трафика из сети Wi-Fi к EPC. Этот интерфейс основан на протоколе PMIPv6 (Proxi Mobile IP v6). Так же, как и S2c, этот интерфейс терминируется на P-GW и обеспечивает получение полной картины пользовательского трафика. Отличие между двумя описанными интерфейсами состоит в том, что PMIPv6 не требует внесения каких-либо изменений в пользовательское оборудование. WAG в доверенной не-3GPP IP-сети предоставляет функции мобильного IP (Mobile IP) прозрачно для клиента. WAG формирует туннель, запрашивает IP-адрес от P-GW и затем ассоциирует этот IP-адрес с сессией Wi-Fi. В данном случае пользовательское устройство получает IP-адрес из пула P-GW, но это не некий виртуальный адрес, а IP-адрес, который физически используется радиоинтерфейсом Wi-Fi на устройстве пользователя, см рис 12.
Рисунок 12.
Архитектура LTE.
Были представлены для метода интеграции: через S2a и через S2c. Каждый метод имеет различные показания к использованию. Модель на основе S2c требует внесения изменений в пользовательское оборудование, таким образом, это метод с вовлечением клиента. Такой метод может быть весьма не тривиальным при применении в мобильной сети, т.к. потребует установки специального программного обеспечения на клиентское устройство (это может быть специальное приложение, поддерживающее DSMIPv6 прим. komway.ru). При этом мобильный оператор должен обеспечить, что такое приложение сможет работать на большом количестве мобильных устройств и операционных систем, а также обеспечить возможность загрузки новых версий данного ПО впоследствии. Также важно замотивировать пользователей использовать такое ПО. Рисунок 13 показывает установление такой сессии, определяемой по 3GPP. В фазе А показано соединение к сети Wi-Fi, в фазе B туннель DSMIPv6 строится к P-GW. В фазе С сессия становится активной. Также показана установка политик для сессии, используя PCRF.
Рисунок 13.
Вход в сеть через S2c, как определено в 3GPP.
Подход с использованием интерфейса S2a обходит проблему необходимости применения специально клиентского ПО. Но возникает ситуация, когда оператор теряет контроль активации Wi-Fi сессии и хендовера сессии на пользовательском устройстве. Потеря такого контроля может вести к непредсказуемому поведению клиентского устройства в процессе переключения с сети доступа 3GPP в сеть Wi-Fi и обратно. На рисунке 14 представлен вход в сеть, как определено в 3GPP. Доверенная не-3GPP сеть IP-доступа представлена сетью Wi-Fi с WAG, как часть этой сети. Для более детального описания Call Flow см. 3GPP TS 23.402.
Рисунок 14.
Вход в сеть через S2a, как определено в 3GPP.
Хендовер между радиоинтерфейсами WiFi и мобильной сети
До начала анализа различных методов хендовера важно разобраться с терминами, которые используются в этом контексте. Особенно важно понимать, что такое хендовер сессии и какие типы хендовера могут использоваться в зависимости от требования мобильного оператора.
В мобильных сетях (с передачей данных) хендовер является одной из важнейших процедур - когда пользователь перемещается из зоны действия одной радиостанции к другой (чаще всего речь о мобильных базовых станциях или точках доступа WiFi-стандарта, прим. komway.ru). Процедура хендовера описывает поведение сети когда пользователь переключается с одного типа радио на другой (например с 3G на Wi-Fi).
На сегодняшний день несколько типов хендоверов могут использоваться. Выбор какого-либо конкретного типа в сети мобильного оператора должен подразумевать необходимый баланс между ожиданиями пользователей и сложностью архитектуры решения.
1. Хендовер без постоянной поддержки IP-адреса (хендовер связности с сетью): Когда пользователь присоединяется к сети стандарта Wi-Fi, то он прозрачно аутентифицируется и получает новый IP-адрес от сети Wi-Fi. Все новые коммуникации пользователя могут использовать этот новый назначенный IP-адрес как источник. Все ранее установленные TCP и/или UDP соединения в сети 3G, тем не менее, могут продолжаться через сеть 3G. Если логика, имплементированная в пользовательское устройство, подразумевает отключение 3G интерфейса (например, в случае входа в WiFi-сеть, устройство может принудительно отключать пакетную часть 3G, прим. komway.ru), тогда уже установленные соединения должны будут автоматически переустановиться через сеть стандарта Wi-Fi, но с использованием нового IP-адреса.
2. Хендовер с постоянной подддержкой IP-адреса (IP-хендовер): Когда пользователь присоединяется к сети стандарта Wi-Fi, то пользователю будет назначен тот же IP-адрес, который он использовал в 3G или LTE сети. Если установленные TCP и/или UDP соединения связаны с физическим интерфейсом (учитывая обычную модель имплементации стека TCP/UDP на пользовательском устройстве), тогда эти соединения все равно будут автоматически переустановлены через Wi-Fi даже с учетом использования одного и того же IP-адреса.
3. Сессионный хендовер (прозрачный хендовер): Данный тип подобен IP-хендоверу, но он должен происходить во временном интервале, позволяющем работать медийным приложениям реального времени (Голос/VoIP, Потоковое видео и т.п.). Например, используя уже установленные сокеты: UDP для медийного трафика и TCP обмена контрольными сообщениями медийной сессии, продолжать этот процесс без прерывания или деградации в уровне услуги, заметной для пользователя, когда мобильное устройство переключается между Wi-Fi и 3G. (Основная идея в реализации быстрого хендовера с использованием одного IP-адреса, но так, чтобы собственные механизмы буферизации в приложении смогли успеть компенсировать время переустановления UDP и TCP сокетов при переходе из 3G в Wi-Fi и наборот, прим. komway.ru).
Важно знать, что бесшовный хендовер может быть получен только во взаимодействии с устройством пользователя (когда сеть может взаимодействовать с мобильным устройством, прим. komway.ru). Для этого необходимо проводить модернизацию существующего программного обеспечения клиентских устройств. Как минимум, необходимо ПО для формирования виртуального интерфейсного адаптера для маскирования структуры физических интерфейсов для сокетов TCP и UDP.
3GPP определяет механизмы хендоверов для доверенной сети стандарта Wi-Fi только как части LTE-архитектуры. Для недоверенной сети Wi-Fi варианты существуют как для 3G, так и для LTE.
Хендоверы на основе S2a (без клиента/clientless)
Преимущество PMIPv6, как протокола для S2a интерфейса, состоит в том, что этот протокол был разработан для мобильности IP-трафика, обеспечиваемой сетью. Таким образом, он может обеспечить, без улучшений на стороне клиента, хендовер IP-адресов между различными типами доступа. В данном дизайне P-GW отвечает за закрепление и контроль сессии, назначение IP-адресов и переключение PMIPv6- или GTP-туннелей между различными шлюзами доступа в случае необходимости хендовера. Такие шлюзы доступа должны поддерживать функцию MAG (Mobile Access Gateway) для обеспечения всех функций мобильного IP-узла, см рис 15.
Рисунок 15.
Последовательность действий при хендовере в соответствии с 3GPP TS 23.402.
Хотя хендовер на основе S2a выполняется без клиента, помните, что основные проблемы хендовера между Wi-Fi и 3G лежат в плоскости присутствия двух радиоинтерфейсов на устройстве пользователя и роли пользовательского устройства при принятии решения о выполнении хендовера. Из-за этих двух факторов сеть ни при каком условии не может самостоятельно гарантировать, что пользовательское устройство использует корректный радиоинтерфейс. Определение того, что считать подходящим/корректным интерфейсом, может меняться от оператора к оператору.
Также на пользовательском устройстве стек TCP/IP должен быть связан с двумя физическими радиоинтерфейсами, которые могут со временем иметь идентичные IP-адреса. В дополнение к этому в некоторых вариантах имплементации стека TCP/IP сокеты приложений могут быть связаны с каким-либо физическим интерфейсом. Таким образом, когда пользовательское устройство или приложение переключается между интерфейсами, то сессии приложения должны быть прерваны и может потребоваться переустановка сессий через новый интерфейс.
С учетом всех представленных зависимостей архитектура на основе PMIPv6 не может гарантировать (без участия пользовательского оборудования) прозрачный хендовер для всех типов пользовательских устройств. Такая ситуация может быть существенно улучшена с помощью установки на пользовательское устройство правильно спроектированного менеджера соединений, использующего виртуальные адаптеры (чаще всего такой менеджер является частью специализированного мобильного приложения, прим. komway.ru).
Хендоверы на основе S2с (с участием клиента/client-based)
Для интерфейса S2c 3GPP использует протокол DSMIPv6, разработанный IETF, между устройством пользователя и P-GW, работающего точкой привязки сессий. Находясь в не-3GPP сети, мобильное устройство формирует DSMIPv6 к подходящему P-GW и ему назначается виртуальный IP-адрес, который затем используется для коммуникаций приложений. Тот же IP-адрес будет назначен устройству и на сети 3GPP в случае хендовера в эту сеть. 3GPP рассматривается как домашняя сеть, и, таким образом, пользовательскому устройству нет необходимости устанавливать DSMIPv6-туннель к 3GPP сети, см рис 16.
Рисунок 16.
Последовательность шагов при хендовере из сети LTE в сеть Wi-Fi (3GPP TS 23.402).
Хендовер с вовлечением клиентского устройства предоставляет возможности получить прозрачный сервис без необходимости переустановления TCP и UDP сессий, т.к. клиентское ПО маскирует все физические интерфейсы за одним виртуальным адаптером. Все сокеты начинаются с этого виртуального адаптера, и нет необходимости перезапускать стек TCP/IP.
Варианты для хендовера из 3G в сети стандарта Wi-Fi
Хотя эта часть не стандартизована, существует три чаще всего используемых дизайна для обеспечения хендовера между 3G и Wi-Fi сетями доступа. Все они строятся на присутствии P-GW в сети и, таким образом, не напрямую, но требуют модернизации мобильной сети до EPC.
Первый вариант состоит в интеграции 3G-сети в EPC, используя SGSN с поддержкой S4, см рис 17.
Рисунок 17.
Архитектура интеграции 3G-сети в EPC с использованием SGSN, поддерживающего S4.
Эта опция строится на возможности применения P-GW для управления 3G-соединениями с обеспечением хендовера S2a-типа.
Второй вариант состоит в использовании пользовательских устройств с поддержкой S2c. Такие устройства могут сами открывать DSMIPv6-туннель к P-GW через любой тип сети доступа, включая 3G. В таком случае сама сеть 3G не интегрирована внутрь EPC. Однако пользовательские сессии сходятся на P-GW и контролируются им для всех типов доступа. Такой подход может потребовать модернизации систем полисинга и тарификации до стандартов LTE. Также в данном сценарии параметры 3G QoS не видны на P-GW.
Третий вариант состоит в использовании S2a-интерфейса на традиционном 3G GGSN. Здесь 3G соединения проходят как PMIPv6 к P-GW и закрепляются на нем. Данный вариант широко не применяется из-за неразвитой поддержки функционала MAG на большинстве GGSN.
Мобильность между радиосетями. Заключение.
Как было показано, здесь хендовер между радиосетями - это не простая задача. Сегодня стандарты существуют и улучшаются, отражая растущий опыт индустрии. Тем не менее, полнофункциональный прозрачный хендовер не получил широкого распространения в реальных сетях.
Основная проблема лежит в пользовательском оборудовании, поведение которого не предсказуемо. Также варьируются имплементации стека TCP/IP. Решения о присоединении к сети и рассоединении с сетью, принимаемое устройствами различных производителей и различными типами устройств, варьируются. В общем случае системы клиентских устройств имеют тендецию быть закрытыми к модификации программного обеспечения уровня драйверов и поэтому часто не разрешают установку соответствующих программ/приложений операторами. 3GPP и другие институты стандартизации (WBA/Wireless Broadband Alliance, OMA/Open Mobile Alliance) занимаются решением этих проблем с менеджерами соединений и централизованных политик оффлоада трафика (на базе ANDSF/Access Network Discovery and Selection Function), но это требует времени для широкой адаптации.
Недоверенная не-3GPP сеть IP-доступа.
Первые стандарты 3GPP по интеграции WiFi-сети позиционировали WiFi-сети как недоверенный доступ. Было множество причин для этого. В сетях не было безопасной EAP-аутентификации, они не имели шифрования и часто принадлежали сторонним провайдерам услуг. Таким образом, стандарт требовал, чтобы механизмы безопасности были внедрены напрямую между оборудованием пользователя и пакетным ядром.
В общем случае архитектура для недоверенного доступа допускает, что пользователи могут использовать любой тип доступа, к которому они могут присоединиться. После получения соединения клиентское ПО (программный клиент) открывает IP Sec-туннель к пакетному ядру, где туннель проходит аунтентификацию, получает IP-адрес. Затем весь трафик перенаправляется в пакетное ядро. Все функции для PCC могут быть переиспользованы из существующего пакетного ядра. Для реализации данного типа доступа в стандарте была введена функция пакетного ядра TTG (Tunnel Termination Gateway). TTG отвечает за терминацию туннелей IP Sec и коммутацию трафика из этих IP Sec-туннелей в GTP-туннели к традиционным GGSN. В LTE-архитектуре эта функция является частью функционала ePDG (evolved Packet Data Gateway).
Оригинал статьи (англ).
Kom-Way.Team
Использование материалов этого сайта разрешено только с согласия komway.ru и наличии прямой ссылки на источник.
