Особенности управления и организации соединений – ЧАСТЬ 1

5.2.3.8.                Сервисные потоки и управление качеством. Сервисные потоки являются ключевым механизмом обеспечения качества предоставляемой услуги в стандартах семейства IEEE 802.16. Каждый поток характеризуется определен­ным набором требований к каналу передачи: по времени задержки в передачи символа и его флуктуациям (джиттер), гарантированной пропускной способно­сти и др. Каждому сервисному потоку сеть присваивает 32-разрядный иденти­фикатор сервисного потока SFID, по которому БС задает параметры соедине­ния, связанного с этим сервисным потоком.

Транспортная среда IEEE 802.16 формирует коммуникационные каналы для потоков данных разных приложений (сервисов): IP, видеоданных, ATM, пакетов типа Е1 и VoIP и др. Каждое из приложений обладает своими требованиями к скорости передачи, надежности и криптозащите. Данные каждого приложения передаются по радиоканалу с учетом своей специфики. В целях стандартизации была также введена категория сервисного класса (это набор параметров пере­дачи для типового приложения).

Как уже отмечалось, классификация сервисных потоков осуществляется на подуровне конвергенции. Она сводится к сопоставлению соответствую­щих полей в заголовке пакета, пришедшего с верхнего уровня, с набором классификаторов. При обнаружении соответствия идентификаторы CID и SFID ассоциируются с пакетом и параметры сервисных потоков передаются в управляющем сообщении DSC-RSP (т.н. сообщении динамического изме­нения услуги [5,6]).

Для контроля QoS в стандарте IEEE 802.16 также используются меха­низмы: формирования очередей; резервирования полосы частот (Unsolicited Grant Service, UGS); опроса rt-PS (Real Time Polling Service) (для услуг реального времени); опроса nrt-PS (Non-Real Time Polling Service) (для услуг, не требующих качества реального времени), а также обслуживания по остаточному принципу (Best Effort, BE). Такие параметры, как пиковая и гарантированная скорость передачи данных (Peak Data Rate и Guaranteed Data Rate) наряду с приоритетом (или категорией обслуживания) пользо­вателя для каждой отдельной услуги и направления связи формируются не­зависимо.

5.2.3.9.                Управляющие сообщения. Управляющие сообщения являются основным механизмом управления в сетях WiMAX. Все функции управления:

Типы управляющих сообщений в стандарте IEEE 802.16-2004

описание профилей пакетов, управление доступом, криптозащита – реализуют­ся через управляющие сообщения. В зависимости от типа управляющего со­единения сообщения делятся на три категории: широковещательные, базовые и первичные. В первых версиях стандарта (например, в IEEE 802.16а) управ­ляющих сообщений было 32, в то время как в стандарте IEEE 802.16-2004 их число выросло до 49 (см. табл. 5.4). В последней версии стандарта IEEE 802.16е зарезервировано 256 типов управляющих сообщений [2,6].

Таблица 5.4

Тип

Имя сообщения

Описание сообщения

Соединение

1

2

3

4

0

UCD

Дескриптор обратного канала

Широкове­щательное

1

DCD

Дескриптор прямого канала

Широкове­щательное

2

DL-MAP

Определение доступа к прямому каналу

Широкове­щательное

3

UL-MAP

Определение доступа к обратному каналу

Широкове­щательное

4

RNG-REQ

Запрос диапазона

Базовое

с

J

RNG-RSP

Отклик диапазона

Базовое

6

REG-REQ

Запрос регистрации

Первичное

7

REG-RSP

Отклик регистрации

Первичное

8

Зарезервировано

9

PKM-REQ

Запрос управления ключом конфиденциальности

Первичное

10

PKM-RSP

Отклик на запрос управления ключом конфиденциальности

Первичное

11

DSA-REQ

Запрос добавления динамического сервиса

Первичное

12

DSA-RSP

Отклик добавления динамического сервиса

Первичное

13

DSA-ACK

Подтверждение добавления динамического сервиса

Первичное

14

DSC-REQ

Запрос изменения динамического сервиса

Первичное

15

DSC-RSP

Отклик изменения динамического сервиса

Первичное __

16

DSC-ACK

Подтверждение изменения динамического сервиса

Первичное

17

DSD-REQ

Запрос аннулирования динамического сервиса

Первичное

18

DSD-RSP

Отклик аннулирования динамического сервиса

Первичное

19-20

Зарезервировано —

21

MCA-REQ

Запрос мультикастингового присвоения

Базовое

22

MCA-RSP

Отклик мультикастингового присвоения

Базовое :_____

23

DBPC-REQ

Запрос изменения профиля прямого канала

Базовое______

Продолжение таблицы 5.4

1

2

3

4

24

DBPC-RSP

Отклик изменения профиля прямого канала

Базовое

25

RES-CMD

Команда сброса

Базовое

26

SBC-REQ

Запрос базовых возможностей SS

Базовое

27

SBC-RSP

Отклик базовых возможностей SS

Базовое

28

CLK-CMP

Сравнение показаний сетевых часов SS

Широкове­щательное

29

DREG-CMD

Команда регистрации или ее отмены

Базовое

30

DSX-RVD

Сообщение получения DSx

Первичное

31

TFTP-CPLT

Сообщение завершения конфигурационного файла TFTP

Первичное

32

TFTP-REP

Отклик завершения конфигурационного файла TFTP

Первичное

33

ARQ-Feedback

Одиночная ARQ обратная связь

Базовое

34

ARQ-Discart

Сообщение о сбросе ARQ

Базовое

35

ARQ:Reset

Переустановка ARQ

Базовое

36

REP-REQ

Запрос о данных измерения в канале

Базовое

37

REP-RSP

Отклик на запрос о данных измерения

Базовое

38

FPS

Быстрое управление мощностью

Широкове­щательное

39

MSH-NCFG

Конфигурация Mesh-cera

Широкове­щательное

40

MSH-NENT

Вход в режим Mesh-cera

Базовое

41

MSH-DSCH

Список дистрибутивов Mesh-cera

Широкове­щательное

42

MSH-CSCH

Централизованный список Mesh-cera

Широкове­щательное

43

MSH-CSCF

Конфигурация списка Mesh-сети

Широкове­щательное

44

AAS-FBCK-REQ

Запрос A AS с обратной связью

Базовое

45

AAS-FBCK-RSP

Отклик на запрос AAS с обратной связью

Базовое

46

AAS Beam Select

Сообщение выбора балансировки AAS

Базовое

47

AAS BEAM REQ

Сообщение о запросе балансировки AAS

Базовое

48

AASBEAMRSP

Отклик на сообщение о запросе балансировки AAS

Базовое

49

DREG-REQ

Сообщение о прекращении регистрации станции пользователя

Базовое

50-255

Зарезервировано 1

Каждое из управляющих сообщений имеет свое назначение. Так, сообще­ния дескриптора прямого и обратного каналов служат для обеспечения дина­мической оценки параметров качества передачи. В качестве примера в табхг 5^5 приведены форматы и назначения управляющих сообщений UCD и UL-MAP. Подробные сведения об управляющих сообщениях в стандарте ШЕЕ 802.16 со­держатся в [6].

Таблица 5.5

Имя сообщения

Назначение

Формат сообщения

Синтаксис

Размер

UCD

Периодически передается базовой станцией для определения характеристик физического обратного канала

UCDMassegeFormat {

 

Тип управляющего сообщения

8 бит

Счетчик изменения конфигурации

8 бит

Начало отсрочки передачи

8 бит

Конец отсрочки передачи

8 бит

Запрос начала отсрочки

8 бит

Запрос конца отсрочки

8 бит

Информация о канале в кодировке TLV

перемен­ный

Начало секции специфической для PHY{

 

for (i=l; i<=n; i++) {

 

Профиль пакета на линии uplink

перемен­ный

}}}

 

I

 

}

 

UL-MAP

Определяет порядок доступа к обратному каналу

UL-MAP_Massege_Format {

 

Тип управляющего сообщения

8 бит

Идентификатор обратного канала

8 бит

Счетчик UCD

8 бит

Число элементов UL-MAP п

8 бит

Начало времени предоставления

32 бита

Начало секции, специфической для PHY{

 

for (i=l; i<=n; i++) {

 

UL-MAP_Information_Element}

перемен­ный

} }

 

5.2.3.3. Организация соединений. Под организацией соединения в IEEE 802.16 понимают установление логической связи между передающей и при­емной стороной на MAC-уровне для передачи сервисного потока. Каждому соединению присваивается 16-разрядный идентификатор соединения CID, задающий тип и характеристики соединения. Формат CID показан на рис. 5.5 [6]. По CID базовая станция однозначным образом определяет тип сервисно­го потока и параметры, необходимые для его передачи. Как уже отмечалось выше, разные приложения характеризуются различными требованиями по скорости, качеству, безопасности и другим параметрам, которые необходимо учитывать при передаче потоков данных по радиоканалу.

Назначение и формат управляющих сообщений UCD и UL-MAP

Для сетей с топологией Mesh (см. подраздел 5.2.7) обычная структура иден­тификатора CID дополняется 8-битовой приставкой Link ID.

Рис. 5.5. Структура идентификатора соединения (CID)

Как уже отмечалось выше, классификация соединений осуществляется по служебным заголовкам блоков данных приложений верхних уровней. Напри­мер, классификатором соединения по протоколу ATM является набор параме­тров ATM-ячейки – а именно, 8-битовый идентификатор виртуального маршру­та VPI (Virtual Path Identifier) и 16-битовый идентификатор виртуального канала VCI (Virtual Channel Identifier) [2,6].

5.2.3.4. Механизмы пыделения канальных ресурсов. Доступ к кана­лам в IEEE 802.16 осуществляется путем передачи пользовательской стан­цией запроса на обслуживание – DAMA (Demand Assigned Multiple Access) [2,4]. Выделяют два типа запросов – случайные и плановые. Кроме того, стандартом определяются две категории запросов: запрос на предостав­ление ресурса и запрос на изменение ресурса. Реакцией на запрос может быть разрешение на обмен информационными потоками, а также назначе­ние временного интервала передачи в обратном канале. Эта информация отображается в служебном сообщении UL-MAP прямого канала. Запросы на изменение ресурса передаются в служебных сообщениях UCD (Uplink Channel Descriptor).

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

Процедура плановых запросов называется системным опросом (polling) [4]. Базовая станция заранее резервирует и предоставляет пользовательской станции интервал для передачи запроса о предоставлении или изменении Ресурса. Как следствие, конкуренция в доступе между разными пользова­тельскими станциями в таких случаях отсутствует, ч-о и обусловливает от­сутствие коллизий.

Системный опрос осуществляется в двух режимах: в режиме «реального времени» (Real-Time) и «вне реального времени» (Non-Real-Time). В режиме

«реального времени» базовая станция предоставляет пользовательской станции

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

В режиме «вне реального времени» БС предоставляет ПС аналогичный ин­тервал для передачи запроса, однако задержка в предоставлении интервала до­ступа гораздо больше, чем в первом случае. Данный режим удобен для работы с приложениями по FTP-протоколу [4].

Получив ответ базовой станции на запрос о предоставлении полосы, ПС в течении первых трех тактовых интервалов начинает передачу данных. Ина­че, ПС повторно запрашивает необходимую полосу частот на конкурентной основе.

При отсутствии в течении 16 тактовых интервалов ответа базовой станции на запрос пользовательской станции о предоставлении полосы последняя теряет право конкурентного доступа. Это означает, что ресурс базовой станции задей­ствован полностью и в данный момент времени она не может предоставить ПС интервал для передачи данных.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100