Приоритезация трафика в пакетной сети

18 октября 2013  |  Рубрики: Evil Operator
На одном из последних проектов где я участвовал, выясняли возможность приоритезации пакетных данных для различный сценариев. В ходе проектирования выяснилось несколько весьма интересных деталей по возможной оценке трафика на SGSN/GGSN и его дальнейшей обработке, которыми собственно и хотелось бы поделиться с моими читателями.

Intro

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

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

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

  • Common data traffic (трафик от любого приложения без необходимости приоритетной доставки)
  • Real-time media traffic (стриминг трафик с необходимостью приоритетной доставки и повышенными требования обслуживания (QoS): голосовые сервисы, real-time chatting, Group Chat, FileTransfer, etc.
  • Signalling traffic (сигнальный трафик, использующийся для корректировки работы приложений – биллинг, сервисная информация и т.д.)

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

Так вот, в ходе проектирования были выявлены две основные схемы реализации приоритезации потоков на уровне PS Core сети: single-address & multi-address.

Более детальная информация предоставлена на схеме ниже:

Traffic prioritization

 

Single-address схема предполагает что со стороны мобильного терминала абонента поднимается основной (Primary) PDP Context, а затем несколько второстепенных (Secondary) PDP Context’ов на базе основного. При этом все эти потоки данных т.е. активированные PDP Context’ы от мобильного терминала (МТ) будут подняты со своими отдельными профилями предоставления услуг (QoS), но на одну ту же APN и IP адрес. Данная схема предполагает более рациональное использование адресных ресурсов, но в то же время требует наличия определенной функциональности на сети оператора. В частности, на GGSN‘е должна быть реализована т.н функциональность TFT (Traffic Flow Template), которая представляет собой своего рода таблицу соответствия идентификаторов PDP Context’ов (включая NSAPI) и их адресов для осуществления правильного роутинга пакетов.

Вторая схема, multi-address предполагает что все PDP Context’ы будут подняты на отдельные APN, что позволит также назначить каждому из них свои профили предоставляемых услуг QoS, а также каждому из них будут предоставлены свои IP адреса. В данном случае реализуется более простая схема обслуживания контекстов приложения, но требует создания и резервирования большего количества ресурсов. Для этой схемы оператор по договоренности с провайдером услуг создает набор APN и соответственно с помощью них определяет во-первых куда перенаправить потоки данных от абонента, а во-вторых будет иметь возможность назначить каждому из потоков данных свой профиль обслуживания.

Более детально по поводу поднятия нескольких PDP Context’ов можно почитать вот здесь и тут.

Traffic detection

Для осуществления тарификации абонентов по используемым ими сервисам, а также для корректного взаиморасчета, проверки используемого трафика и как следствие создание специальных правил тарификации приложений по используемому трафику предполагается что на сети оператора присутствует функциональность DPI (Deep Packet Inspection) или аналоничная ей.

В целом, идентификация трафика может быть основана на анализе различных уровней в сетевой модели OSI: Транспортных/Сетевых [L3/L4] или уровне приложений – L7/L7+, относящихся к DPI механизмам. При этом эти правила могут быть определенны как на самом сетевом элементе (GGSN’е например), так и быть доступны по протоколам RADIUS/Diameter на отдельным Policy Servers.

Если говорить в разрезе анализа трафика на более низких уровнях (L3/L4), то идентификация трафика происходит путем анализа IP headers TCP протокола или хедеров UDP, где в качестве основных параметров по которым идет различение могут выступать:

  • IP destination адреса и подсети
  • TCP/UDP destination ports или port ranges
  • IP protocol number, as defined in the IP header (RFC 791)
  • Доменные имена

Управления приоритезацией трафика после его выделения и общего потока возможно организовать с помощью различных механизмов. В частности можно определить rating-group и назначить ей как определенный приоритет (обозначить профиль обслуживания такого трафика – QoS) так и специальное правило тарификации.

Если сделать небольшой отступление и копнуть глубже в сторону QoS применяемых на пакетной сети, то можно сказать во-первых что класс QoS выбирается индивидуально для каждой новой сессии передачи данных. При этом кроме QoS, в характеристику сессии передачи данных входит тип протокола (PDP type – Packet Data Protocol type); PDP-адрес, выданный мобильной станции (выдача адресов бывает как статической, так и динамической); а также адрес GGSN, с которым идет работа. При этом PDP context записывается в телефон, а также в обслуживающие его SGSN и GGSN. Одновременно может поддерживаться несколько профилей передачи данных для каждого пользователя.

Вообще говоря, пакетная передача данных предусматривает два режима “соединений”:

  • PTP (Point-To-Point – точка-точка);
  • PTM (Point-To-Multipoint – точка-многоточие).
  • Широковещательный режим РТМ в свою очередь подразделяется на два класса:
  • PTM-M (PTM-Multicast) – передача необходимой информации всем пользователям, находящимся в определенной географической зоне;
  • PTM-G (PTM-Group Call) – данные направляются определенной группе пользователей.

Поддержка режима “многоточечной” передачи информации PTM ожидается в будущих спецификациях GPRS.

Traffic analysis

Для более детального анализа трафика с расширенными возможностями по определению сервисов, предпочтительнее использовать механизмы DPI (Deep Packet Inspection) на уровнях L7/L7+. Такой подход позволяет значительнее расширить горизонты обследуемых протоколов и сервисов, в частности может быть применен анализ url адресов и поведенческих паттернов абонентов. Конечной целью анализа трафика на этих уровнях для нашего случая будет также повышения его приоритета на сети оператора например за счет определенных профилей обслуживания QoS, либо применение т.н. шейперов трафика.

Для нашей схемы предполагается также что на сети оператора реализован механизм тарификации на основе архитектуры PCC (Policy & Charging Control) и ее механизмов или аналогичный, на уровне DPI (Deep Packet Inspection) подсистем, который бы позволил во-первых провести анализ трафика и выделить Destination к которому обращается мобильная компоненты приложения (будь то domain url или IP адрес) и во-вторых назначить специальную тарификацию (рейтинг-группу) для данного направления. Аналогичная схема реализована для сервисов 0.facebook.com, Opera Mini, и т.д. Предполагается также что есть механизмы синхронизации действий и правил работы GGSN элементов через управляющую структуру OMS (Operation & Management System).

Идеальным решением, было бы наличие PCRF и PCEF функциональностей, которые осуществляют взаимодействие по протоколу Diameter и фактически перекрывают необходимость идентификации трафика, его приоритезации и назначения специальных тарифов.

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

Также в данном случае возможен вариант, по согласованию с оператором для сценария когда платформа будет выступать в качестве провайдера правил тарификации сервисов/приложений и создания динамических правил приоретизации трафика. Основное взаимодействие PCRF с платформой будет осуществляться с помощью RADIUS/Diameter протоколов.

В качестве альтернативного вариата на случай, если указанные элементы (PCRF & PCEF) отсутствуют вообще, либо их функциональность ограниченна, либо же они являются логической частью другого сетевого элемента, как может произойти с DPI совмещенным с GGSN – основное взаимодействие может быть организованно через:

  • по протоколу SOAP
  • через структурированный формат JSON

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

  1. Приоретизация трафика для разнородного трафика приложений и сервисов, используемых абонентами мобильного оператора
  2. Создание подсетей пользователей сервисов

В частности под нужды клиентов нашей платформы оператор может выделить подсеть, для всех абонентов обращающихся по определенному сервису (на определенную APN) через механизмы профиля абонента на HLR’е, либо RADIUS ААА сервере.

Вот такие основные моменты мы выяснили на этом проекта и я думаю что подобного рода “исследования” будут сейчас особенно актуальны в разрезе повышающегося спроса на т.н. RCD (Rich Communication Services) для которых приоритезация трафика будет весьма актуальна.

В качестве не выясненных моментов остались вопросы, интеграции с сетью оператора для управления Chargin Policies, возможность управления приоритетом на радио подсети и т.д.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Автор:
1 комментарий | 1 659 просмотров

Комментарии (1) к статье: "Приоритезация трафика в пакетной сети"


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

 

?Раньше искали

CombiSGSN GGSN SGSN GPRS Attach PDP Context SMS over GPRS SMSC GTP-C GTP-U IMSI 

!На хостинг

#Счетчики

Rambler's Top100