В современных сетях передачи данных большое значение имеют службы реального времени (телефония, трансляция видео), предъявляющие повышенные требования к транспортной сети, параметры качества которой прямо влияют на степень удовлетворенности пользователей этими службами, и нередко определяют саму возможность предоставления служб реального времени со стороны операторов связи [1].
Поэтому операторы сети передачи данных стремятся использовать такие технические средства и организационные приемы для построения и обслуживания своей сетевой инфраструктуры, которые позволяют обеспечить и поддерживать адекватный уровень качества работы транспортной сети, как в текущий момент, так и в обозримой перспективе.
Существует несколько способов обеспечения QoS. Самый простой из них - увеличение пропускной способности сети за счет аппаратных возможностей. Очевидно, этот способ не гибок и может быть дорогостоящим при обновлении крупных сетей. Наиболее распространенные проводные сети, типа Ethernet, изначально не реализуют QoS, но существуют другие типы проводных сетей, такие как ATM [2], Frame relay, и др., и которые поддерживают QoS. Таким образом, одним из способов по обеспечению QoS является переход на использование сетей такого типа.
Для наиболее полноценного обеспечения QoS используется комбинированный подход, который, помимо простого увеличения пропускной способности включает «интеллектуальные» методы по уменьшению нагрузки на сеть. Задание приоритетов заключается в разделении трафика на классы. Классификация трафика представляет собой отдельную задачу. Пакеты могут разбиваться на приоритетные классы в зависимости от настроек узла связи, приложения, генерирующего трафик, и др.
После выполнения установки приоритетов однотипные по приоритету пакеты собираются в очереди для дальнейшей обработки. Фактически очередь представляет собой некий участок памяти маршрутизатора или коммутатора, в котором организуются для обработки пакеты одного класса
Обеспечения качества обслуживания в сетях WiMAX (стандарт 802.16) [1, 4, 5] определяет несколько принципов:
- планирование параметров QoS сервисного потока [3];
- динамическое установление сервиса;
- двухфазная модель активации.
Различные механизмы протокола 802.16 могут использоваться для поддержки QoS. Требования QoS включают в себя следующее:
- Функции конфигурирования и регистрации для предварительного конфигурирования параметров QoS сервисного потока и параметров трафика [78] на АС.
- Функцию сигнализации для динамической установки QoS сервисного потока и параметров трафика.
- Применение МАС-планирования и QoS-параметров трафика для потоков UL.
- Применение QoS-параметров трафика для потоков DL.
- Группировку свойств сервисного потока в именованный класс сервиса (Service Class), так что объекты верхних уровней и внешние приложения (БС и АС) могли запросить сервисный поток с желаемыми параметрами QoS.
Принципиальный механизм обеспечения QoS – привязка пакетов, проходящих через МАС- интерфейс, к потоку сервиса посредством CID [20]. Основная цель QoS состоит в упорядочивании передачи и планировании использования радиоинтерфейса [6]. Потоки сервиса существуют как в прямом, так и в обратном направлении и могут существовать, не будучи активированными, для переноса трафика. Каждый сервисный поток имеет 32-битный SFID, утвержденные и активированные потоки имеют 16-битный CID.
Поток сервиса характеризуется набором параметров QoS [4], таких как задержка, дрожание, гарантированная пропускная способность.'
Поток сервиса частично характеризуется следующими атрибутами:
- Service Flow ID (SFID) - идентификатор, который обязательно присваивается каждому потоку сервиса.
- C1D: отображение соединения в SFID, которое существует только для утвержденных или активных потоков.
- ProvisionedQoSParamSet: набор возможных параметров устанавливается средствами за пределами стандарта, такими как система управления сетью.
- AdmittedQoSParamSet: набор утвержденных параметров для которых БС (и возможно АС) резервируют ресурсы. Основнымы ресурсами.-являются полоса пропускания, память, время и т.п.
- ActiveQoSParamSet: набор активных параметров, определяющих действующий сервис.
- Authorization Module: модуль авторизации - логическая функция в БС, которая утверждает или отказывает в изменении QoS параметров и классификаторов, ассоциированных с потоком сервиса. Она ограничивает возможные значения параметров AdmittedQoSParamSet и ActiveQoSParamSet.
Соотношение между наборами параметров показано на рис. 1. Набор активных параметров всегда является подмножеством (требует меньшего количества ресурсов) набора утвержденных параметров, который, в свою очередь, есть подмножество авторизированной оболочки. При динамической авторизации эта оболочка определяется с помощью модуля авторизации. В случае статической авторизации оболочка определяется набором возможных параметров[7].
Рис. 1. Модель авторизированной оболочки:
а) статическая авторизация; б) динамическая авторизация.
Объектная модель Ров представлена на рис. 2. Поток сервиса - ключевое понятие МАС- протокола. Поток сервиса идентифицируется уникальным 32-битным идентификатором SFID Поток может быть прямым или обратным. Утвержденные и активные потоки отображаются на 16- битные его.
Рис. 1.2. Объектная модель QoS
Класс сервиса - необязательный объект, который может быть реализован на БС. Класс идентифицируется текстовым именем и имеет набор параметров QoS. Поток сервиса может ссылаться на имя класса для выбора параметров QoS. Набор параметров QoS потока может быть шире установок класса и может отличаться от установок класса в зависимости от процедуры авторизации БС.
Классы сервиса
Классы сервиса служат следующим целям:
- Позволяет оператору перенести бремя конфигурирования сервисных потоков из инициапизационного сервера в БС. Оператор задает для абонентских станций имя класса сервиса. Реализация имени конфигурируется на БС. Это позволяет оператору изменять реализацию сервиса, ничего не меняя на АС. Например, профиль сервиса может меняться в течение дня [10].
- Позволяет протоколам верхнего уровня создавать потоки сервиса по имени класса.
Любой поток сервиса может иметь свой набор параметров QoS, определяемый одним из трех способов.
- явным описанием всех параметров трафика
- ссылкой на параметры трафика, определяемые именем класса сервиса
- ссылкой на имя класса сервиса и модификацией отдельных параметров.
Имя класса сервиса «расширяется» набором параметров в то время, когда БС успешно утверждает поток сервиса. Параметры передаются со стороны БС в сообщениях DSA-REQ, DSC- REQ, DSA-RSP, DSC-RSP. Во всех случаях БС должна включает в сообщение имя класса сервиса и набор параметров данного класса. Если со стороны АС приходит запрос, содержащий дополнительные или модифицированные параметры, то ответ должен включать в себя эти параметры.
Если имя класса сервиса передается в запросе на утверждение или активизацию, то возвращаемый набор параметров может быть, разным для разных активизаций. Это может произойти вследствие изменения параметров Q0S для данного класса на БС. Изменение параметров класса на БС не влияет на активные потоки сервиса.
Когда АС использует имя класса для определения набора утвержденных параметров, то кодированные значения (TLV) набора параметров должны быть возвращен АС в ответах на DSA-RSP или DSC-RSP. Использование имени класса при последующей активизации может привести к отказу, если определение класса изменилось [11]. Поэтому АС для активации должна явно использовать набор параметров, который был получен ранее в ответах.
Каждое изменение параметров Q0S потока сервиса должно быть подтверждено модулем авторизации. Это относится каждому DSA-REQ сообщению для создания нового сервиса и к каждому DSC-REQ сообщению для изменения параметров сервиса. Эти изменения требуют запроса управляющего решения и запроса активизации потока. Запросы на сокращение утвержденных и активизированных ресурсов также должны проверяться модулем авторизации.
В случае статической модели авторизации модуль авторизации хранит возможные значения параметров для всех «отложенных» потоков. Запросы на утверждение и активизацию потоков сервиса должны быть подтверждены, поскольку запросы на изменение набора возможных
параметров должны отклоняться, так же как и запросы на создание новых динамических потоков сервиса. Эти правила определяют статическую систему, в которой все возможные сервиса определены в начальной конфигурации АС [9].
При динамической авторизации модуль авторизации взаимодействует через отдельный интерфейс с независимым сервером политики. Этот сервер может сообщить модулю авторизации необходимую информацию (допустимый набор параметров) для принятия решения на запросы утверждения и активизации. Запрашиваемые параметры должны быть подмножеством набора параметров, полученных от сервера политики.
До начала процедуры установления соединения БС должна извлечь набор возможных параметров для АС. БС должна быть способна использовать эту информацию для динамической авторизации потоков. В БС должен быть реализован механизм аннулирования процесса автоматического подтверждения. Например, данный механизм может
- отвергать все запросы, вне зависимости от того, как они были сконфигурированы;
- определять внутреннюю таблицу с более широким механизмом политики, но на основе набора возможных параметров;
- перенаправлять все запросы к серверу внешней политики.
Поток сервиса кодируется либо полным определением набора параметров или именем класса сервиса. Имя класса сервиса - это строка, известная на БС и неявно определяющая набор параметров QoS.
Возможность управления каждым специфичным параметром потока сервиса является опциональной.
Динамическое создание потока сервиса инициируется БС (обязательная возможность) или АС (опциональная возможность). Создание потока сервиса по инициативе АС показано на рис. 3. Запрос DSA-REQ от АС содержит ссылку на поток сервиса и набор параметров QoS. БС отвечает сообщением DSA-RSP, принимая или отвергая запрос. Если запрос отвергается, то в ответе может содержаться параметр, по которому произошел отказ. DSA-REQ от БС содержит SFID для прямого или обратного потока сервиса, возможно CID, и набор активных или утвержденных параметров. АС отвечает сообщением DSA-RSP, принимая или отвергая запрос. Если запрос отвергается, то в ответе может содержаться параметр, по которому произошел отказ [8].
Рис. 3. Поток сообщения а) инициировано АС; б) инициировано БС
Сегодня беспроводные сети позволяют предоставить подключение пользователей там, где затруднено кабельное подключение или необходима полная мобильность. При этом беспроводные сети взаимодействуют с проводными сетями. На основе анализа существующих алгоритмов управления качеством обслуживания поставлена задача: разработать алгоритм планирования и управления доступом.
ЛИТЕРАТУРА
- Вишневский В.М. Теоретические основы проектирования компьютерных сетей // Москва: Техносфера,2003. - 512с
- Alvarion Ltd. Introducing WiMAX-The next broadband wireless revolution // Alvarion Ltd, 2004.
- Вишневский В.М., Ляхов А.И., Портной С.Л., Шахнович И.В. Широкополосные беспроводные сети передачи информации // Москва: Техносфера, 2005 - 592 с.
- Семенов Ю.А. (ГНЦ ИТЭФ), Качество обслуживание (QoS) в локальных сетях и не только// http://book.itep.ru/4/44/qos lan.htm
- Семенов Ю.А. (ГНЦ ИТЭФ). Стандарт широкополосной беспроводной связи IEEE 802. 16// book.itep.ru
- IEEE 802.16-2004. IEEE standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems // Oct. 2004.
- Бураков М.В. Механизм адаптации нечёткого регулятора. – Известия академии наук // Теория и системы управления №1, 1998, 84-87 - б.
- IEEE 802.16 Working Group on Broadband Wireless Access // http://vvirelessman.org
- Столингс В. Современные компьютерные сети. 2-е изд. - СПб: Изд-во «Питер», 2003.-783 б.
- Ляхов А.И., Мациев Д.Н., Лаконцев Д.В., Шелихов О.Н. Сбор и анализ характеристик функционирования действующей беспроводной сети на основе протокола IEEE 802.11// VIII международная конференция по информационным сетям, системам и технологиям (МКИСС иТ-2007). -СПб.:2007. 225-235 б.
- Вишневскии В.М., Портной С.Л., Шахнович И.В. Энциклопедия WiMAX. Путь к 4G. –М.: Техносфера, 2009. - 472 б.