CITKIT.ru
3 терабайта свободного софта!
Logo    
IT-рынок Новости мира IT Океан(!) софта на CITKIT.ru Форумы Поступления в библиотеку Учебный центр Курилка
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

16.05.2005

Google
WWW CITForum.ru

Новости мира IT:

  • 11.05 - Intel создает свою группу по Open Source
  • 11.05 - Банк контролирует использование USB устройств при помощи DeviceLock
  • 11.05 - Microsoft устранила опасную дыру в Windows
  • 11.05 - "Корпорация ОСС" создает антимонопольный альянс операторов IP-телефонии
  • 11.05 - В Mac OS X найдены множественные уязвимости
  • 11.05 - "Билайн" запускает услугу "Мобильная почта"
  • 11.05 - Две критические уязвимости в браузере Firefox 1.0.3
  • 11.05 - IBM покупает начинающую Open Source-компанию Gluecode
  • 11.05 - Microsoft готова к битве с Open Source за школы
  • 11.05 - Sun завершит "открытие" Solaris в ближайшие 45 дней
  • 11.05 - Создатели браузера Firefox выпускают юбилейные монеты в честь 50 миллионов скачанных копий
  • 11.05 - Вышла пятая версия мобильной ОС от Microsoft
  • 11.05 - Поисковые движки умнеют быстрее, чем люди
  • 11.05 - Фишеры постоянно совершенствуются
  • 11.05 - Специалисты прогнозируют появление аналога Google Adsense от "Яндекс"
  • 06.05 - ICANN озаботилась проблемой торговых марок
  • 06.05 - Google патентует сортировку новостей
  • 06.05 - Intel готовит двуядерные процессоры второго поколения
  • 06.05 - Schoolforge-UK и OSC продвигают Open Source в школы
  • 06.05 - Новая версия рекламной программы подстрекает пользователей купить ПО для своего лечения
  • 06.05 - Microsoft продает ряд своих закрытых разработок
  • 06.05 - Google Labs анонсировал ускоритель интернета
  • 06.05 - Microsoft подвешивает пиратам "морковку"
  • 06.05 - В США входят в обиход "интеллектуальные" тележки для супермаркетов
  • 06.05 - Microsoft работает над аналогом PDF
  • 05.05 - Yahoo video search теперь доступен массам
  • 05.05 - Алмазы помогут бороться с хакерами
  • 05.05 - Интернет-охоту хотят запретить
  • 05.05 - Microsoft привлекает блоггеров для теста Longhorn
  • 05.05 - Основатель Red Hat предложил Стиву Джобсу помощь в решении проблемы с торговой маркой
  • 05.05 - Компьютерная система оргкомитета Кубка мира по футболу 2006 года пострадала от червя Sober
  • 04.05 - Cisco Systems представила многофункциональный продукт Adaptive Security Appliance 5500
  • 04.05 - Администрация Евросоюза поддержала идею всеевропейской интернет-библиотеки
  • 04.05 - Компьютерный вирус дарит билеты на чемпионат мира по футболу
  • 04.05 - Лаборатория Касперского: Обзор вирусной активности - апрель 2005
  • 04.05 - Microsoft хочет отсудить у россиянина два домена
  • 04.05 - Сделка между Lenovo и IBM завершена
  • 04.05 - Эпидемия червя Sober.p зафиксирована в Западной Европе
  • 04.05 - Panda Software публикует отчет о вирусной активности за апрель
  • 03.05 - Институт SANS обновил список наиболее опасных уязвимостей

    Архив новостей >>>


  • 2004 г.

    4.1.8.2 Стандарт широкополосной беспроводной связи IEEE 802.16

    Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

    Бурное развитие разнообразных мобильных телекоммуникаций и пугающее многообразие стандартов эфирного межсетевого обмена продиктовало разработку стандарта, решающего проблему совместимости.

    Стандарт 802.16 (январь 2003) уровня МАС предназначен для реализации широкополосных каналов последней мили в городских сетях (MAN). Его задачей является обеспечения сетевого уровня между локальными сетями (IEEE 802.11) и региональными сетями (WAN), где планируется применение разрабатываемого стандарта IEEE802.20. Эти стандарты совместно со стандартом IEEE 802.15 (PAN - Personal Area Network - Bluetooth) и 802.17 (мосты уровня МАС) образуют взаимосогласованную иерархию протоколов беспроводной связи. WEB-сервер рабочей группы 802.16 размещен по адресу http://grouper.ieee.org/groups/802/16index.html.

    Ниже предлагается конспективное изложение материалов стандарта по документам проектов 2001-2003 годов (полный объем материалов превышает 500 страниц).

    Стандарт покрывает диапазон частот от 2 до 11 ГГц. Стабильность частоты должна лежать в пределах ±10-6. Базовая станция BS), следующая стандарту 802.16, размещается в здании или на вышке и осуществляет связь со станциями клиентов (SS - Subscriber Station) по схеме точка-мультиточка (PMP). Возможен сеточный режим связи (Mesh - сетка связей точка-точка - PTP), когда любые клиенты (SS) могут осуществлять связь между собой непосредственно, а антенные системы, как правило, являются всенаправленными. Базовая станция предоставляет соединение с основной сетью и радиоканалы к другим станциям. Диапазон рабочих расстояний может достигать 30 миль (в случае прямой видимости) при типовом радиусе сети 4-6 миль (для режима Mesh при высоте размещения антенны BS - 50м), где пропускная способность может быть гарантированной. Предусмотрен также режим мультиточка-мультиточка (MP- MP), который имеет ту же функциональность, что и PMP. Клиентская станция (SS) может быть радио терминалом или повторителем (более типично) для организации локального трафика. Трафик может проходить через несколько повторителей, прежде чем достигнет клиента. Антенны в этом случае являются направленными с возможностью дистанционной настройки. Терминальная станция клиента (SS) обычно имеет остронаправленную антенну. По этой причине положение антенны должно быть жестко фиксировано и устойчиво к ветру и другим потенциальным источникам вибрации. Широкополосные системы доступа к радио сети помимо BS и SS содержат клиентское терминальное оборудование (TE), оборудование основной сети, межузловые каналы и повторители (RS). Повторители используются часто тогда, когда между конечными точками канала нет прямой видимости. Повторитель передает сигнал от BS к одной или нескольким SS. В системах MP-MP большинство станция являются повторителями. PTP-соединения (точка-точка) между базовыми станциями могут поддерживать обмен согласно стандартам от DS-3 до OC-3.

    Канал связи предполагает наличие двух практически независимых направлений обмена: отправитель-получатель (uplink - восходящий канал) и получатель-отправитель (downlink - нисходящий канал; по аналогии со спутниковыми каналами). Эти два субканала используют разные неперекрывающиеся частотные диапазоны. Данный стандарт относится к уровню L2, хотя его взаимосвязь с физическим уровнем (PHY) достаточно тесная.

    При формировании радиосетей определенную проблему составляет интерференция сигналов смежных каналов и наложении перекрестных наводок с тепловыми шумами. Для таких каналов отношение I/N (отношение сигнала интерференции к тепловому шуму) лежит в диапазоне -6 ÷ -10 дБ. Следует, разумеется, учитывать, что уровень интерференционного сигнала варьируется в очень широких пределах.

    Радиоволны в диапазоне 10-66 ГГц распространяются прямолинейно и подвержены поглощению при наличии дождя или сильного снега. Любые строения или объекты ландшафта препятствуют их распространению, даже если перекрывают видимость между передающей и принимающей антеннами частично. Рекомендуются вертикальная или горизонтальная ориентации поляризации. Предельное расстояние связи (RH) для высоты положения антенн H1 и H2, сопряженное с кривизной земной поверхности, определяется формулой RH = 4.12(), где RHизмеряется в км, а Н1 и Н2 в метрах.

    Для успешной работы канала нужно обеспечить достаточно большое отношение уровней несущей и интерференционного сигнала (C/I). На практике приходится учитывать отношение C/(I+N), где N - уровень теплового шума, а также уровень шумов приемника (~6дБ). Тепловой шум приемника может иметь уровень -138 дБВт/МГц. Уровень интерференционного сигнала может быть примерно тем же. Эти факторы определяют выбор типа антенны, мощность передатчика и предельную длину канала. Чрезмерное увеличение мощности передатчика (с целью улучшения отношения сигнал-шум) не желательно, так как это приводит к возрастанию уровня интерференционного сигнала.

    Типовыми рекомендуемыми значениями для BS являются:

    Мощность передатчика

    +24 дБм

    Коэффициент усиления антенны SS

    +34 dBi

    Коэффициент усиления антенны BS

    +19 dBi

    Полоса несущей

    28 МГц

    Для SS рекомендуется верхнее значение спектральной плотности < +30дБВт/МГц, аналогичные требования справедливы и для повторителей (RS).

    Будем считать, что типовое значение шума приемника равно 6 дБ, тогда спектральная мощность теплового шума приемника вычисляется по формуле:

    No = 10log(kTo) +NF

    No = -144+6=-138 дБВт/МГц, где

    No - спектральная мощность теплового шума приемника (дБВт/МГц)

    kTo - закон равномерного распределения (-144дБВт/МГц)

    NF - значение шума приемника (6дБ).

    Спектральная плотность потока (psfd) в апертуре антенны вычисляется как:

    где

    Pr= уровень мощности помех усилителя (-144 дБВт/МГц)

    Ае= эффективная апертура антенны

    l = длина волны

    G = коэффициент усиления антенны

    Если рабочая частота равна 28 ГГц (l =0,011м), а значение усиления антенны равно 20 дБi, тогда приемлемый уровень помех определяется как:

    PsfdBS = -144 - 10log(0.0112) - 20 +10 Log(4p)=-114 (дБВт/м2)МГц.

    Заметим, что в данном анализе рассматривалась только базовая станция (составляющая SS не учитывалась). Это в первую очередь связано с тем, что BS обычно размещаются на высоких зданиях и имеют всенаправленные антенны, что увеличивает вероятность обеспечения прямой видимости. С другой стороны SS чаще размещаются на небольших высотах, что уменьшает вероятность гарантированной прямой видимости.

    Стандартный полнодуплексный канал базовой станции может иметь пропускную способность 75 Мбит/с. Такой канал обеспечивает до 60 соединений Т1 и сотни связей с домами, использующими DSL-подключения (при полосе 20 МГц). В последнем случае предоставляется качество обслуживания (QoS) на уровне “наилучшего возможного”. При этом предоставляется минимальные задержки, что важно при передаче голоса (например, в режиме VoIP). Схема взаимодействия радиосетей в случае использования стандарта IEEE 802.16 показана на рис. 1.

    Рис. 1. Место стандарта IEEE 802.16 в системе радио коммуникаций

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

    Продвижением стандарта 802.16 занимается консорциум WiMAX (World Interoperability for Microwave Access), куда входят Fujitsu, Intel и Nokia.

    1. Краткие характеристики стандарта 802.16

    Пропускная способность до 135 Мбит/с при полосе несущей 28 МГц.

    Модуляция OFDM - 64-QAM

    Доступ к среде адаптивный, динамический

    Управление сетью централизованное

    Таблица 1. Краткие характеристики семейства стандартов 802.16

    Название стандарта

    802.16

    802.16a

    802.16e

    Дата принятия

    декабрь 2001

    январь 2003

    середина 2004

    Частотный диапазон

    10-66 ГГц

    2-11 ГГц

    2-6 ГГц

    Быстродействие

    32-135 Мбит/с

    для 28МГц-канала

    до 75 Мбит/с

    для 28МГц-канала

    до 15 Мбит/с
    для 5МГц-канала

    Модуляция

    QPSK, 16QAM, 64QAM

    OFDM 256, QPSK, 16QAM, 64QAM

    OFDM 256, QPSK, 16QAM, 64QAM

    Ширина канала

    20, 25 и 28 МГц

    Регулируемая

    1,5-20МГц

    Регулируемая

    1,5-20МГц

    Радиус действия

    2-5 км

    7-10 км

    макс. радиус 50 км

    2-5 км

    Условия работы

    Прямая видимость

    Работа на отражениях

    Работа на отражениях


    Стандарт 802.16е предназначен для мобильных систем. Безопасность в сети обеспечивается на уровне протокола 3-DES.

    Подуровень конвергенции (CS) размещается поверх уровня МАС. Этот подуровень выполняет следующие функции:

    • воспринимает данные от вышерасположенного уровня

    • осуществляет классификацию этих данных

    • выполняет (если требуется) обработку данных на основе этой классификации

    • транспортирует блоки данных уровня конвергенции соответствующему сервису МАС

    • получает блоки данных от уровня конвергенции партнеров.

    В настоящее время имеются спецификации подуровня конвергенции для асинхронного режима (АТМ) и пакетного субуровня конвергенции. Уровень конвергенции АТМ обеспечивает логический интерфейс, между услугами АТМ и сервисами МАС-уровня. Этот уровень осуществляет классификацию и, если требуется, процедуру PHS (подавление заголовков). При АТМ соединении, которое однозначно идентифицирует пару значений VPI (Virtual Path Identifier) и VCI (Virtual Channel Identifier), является либо виртуальным проходом (VP), либо виртуальным каналом (VC). Классификатором является набор критериев, используемых для каждой ячейки, попадающих на субуровень конвергенции АТМ. В этот набор входит VPI и VCI, а также ссылка на CID (Connection ID). Если ячейка АТМ соответствует этим критериям, она доставляется сервису МАС для пересылки по месту назначения.

    C одним и тем же CID может работать несколько сессий высокого уровня. Например, несколько пользователей могут взаимодействовать через TCP/IP с несколькими различными сетевыми объектами. Следует при этом помнить, что IP-адреса инкапсулируются в поле данных транспортных пакетов.

    Каждый узел имеет свой 48-битовый МАС-адрес (IEEE Std. 802-2001), который однозначно определяет поставщика оборудования и сам узел (как и в Ethernet). Этот адрес используется в процессе регистрации, чтобы установить соединение для SS. Он также применяется в процессе аутентификации, когда BS и SS идентифицируют друг друга. В процессе инициализации SS устанавливаются три управляющих соединения для каждого направления между SS и BS.

    В процессе авторизации в сети узел-кандидат получает 16-битовый идентификатор (Node ID), который используется в дальнейшем во всех операциях. Этот идентификатор используется в сеточном подзаголовке, который следует за общим заголовком кадра. Для обмена с соседями служит 8-битовый идентификатор канала (Link ID). Любой узел присваивает такой идентификатор каждому из осуществляемых соединений и передает его как часть CID (Connection ID - 16 бит) в общем заголовке уникастного сообщения. CID присваиваются посредством сообщений RNG-RSP и REG-RSP. Все это дает возможность реализовать три различных QoS между SS и BS. 16 бит CID позволяют осуществить до 64К соединений для нисходящего и восходящего каналов.

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

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

    Нисходящий канал от базовой станции (BS) до пользователя работает по схеме точка-мультиточка. При этом используется многосекционная антенна, позволяющая осуществлять связь с несколькими клиентами одновременно. В этом режиме BS выполняет простую функцию ретранслятора. В ее задачи при заданной частоте может входить только распределение времени между восходящим и нисходящим каналами. Существует пять различных механизмов диспетчеризации восходящего канала.

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

    В качестве примера рассмотрим примитив запроса формирования соединения (набор параметров запроса).

    MAC_CREATE_CONNECTION.request (

    тип диспетчеризации сервиса,

    подуровень конвергенции,

    параметры сервиса потока,

    индикатор подавления заголовка блока данных,

    индикатор длины,

    индикатор шифрования,

    индикатор управления упаковкой,

    индикатор фиксированной или переменной длины SDU (Service Data Unite)

    Длина SDU,

    запрос CRC,

    параметры ARQ (Automatic Repeat Request),

    порядковый номер )

    В противоположном направлении станция пользователя совместно использует восходящий канал к BS на основе запросов. В зависимости от используемого класса услуг SS может быть предоставлена возможность непрерывной передачи или право передачи получается BS после получения запроса от пользователя. Блок данных МАС-кадра содержит заголовок и опционные поля данных и CRC. Формат МАС блока данных (PDU) представлен на рис. 2.

    Рис. 2. Формат МАС-заголовка (бит 0 является старшим)

    В случае НТ=1 (тип заголовка) место полей Rsv, CI, EKS, Rsv и LEN занимает поле BR.

    Таблица 2. Описания полей МАС-заголовка

    Имя поля

    Длина в битах

    Описание

    CI

    1

    Индикатор CRC

    1= CRC добавляется к полю данных
    0= CRC отсутствует

    CID

    16

    Идентификатор соединения

    EC

    1

    Управление шифрованием
    0= поле данных не зашифровано
    1= данные зашифрованы

    EKS

    2

    Последовательность ключей шифрования

    Индекс ключа шифрования трафика и вектор инициализации для шифрования поля данных. Поле имеет смысл при EC=1

    HCS

    8

    8-битовая контрольная сумма заголовка. Образующий полином: g(D)=D8+D2+D+1.

    HT

    1

    Тип заголовка. Будет установлен равным нулю.

    LEN

    11

    Длина в байтах поля данных и МАС-заголовка

    Тип

    6

    Поле указывает на тип поля данных, включающего подзаголовки

    Значения поля тип для нисходящего канала представлены в таблице ниже

    Таблица 3. Значения поля тип для нисходящего канала

    Тип

    Описание

    0х00

    Подзаголовков нет

    0х01

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

    0х02

    Подзаголовок упакован

    0х03

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

    0х04

    Имеется подзаголовок фрагментации

    0х05-0х3F

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

    Значения поля тип для восходящего канала представлены в таблице ниже

    Таблица 4. Значения поля тип для восходящего канала

    Тип

    Описание

    0х00

    Подзаголовков нет

    0х01

    Имеется подзаголовок Grant Management (основное управление)

    0х02

    Имеется подзаголовок упаковки

    0х03

    Присутствуют подзаголовки Grant Management и упаковки

    0х04

    Имеются подзаголовки фрагментации и Grant Management

    0х05-0х3F

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

    Блок данных (PDU) запроса полосы содержит заголовок запроса полосы пропускания и лишен поля данных. Формат заголовка показан на рис. 3. Запрос полосы имеет следующие свойства:

    Запрос полосы имеет следующие свойства:

    • Длина заголовка всегда имеет 6 байт

    • Поле ЕС устанавливается равным нулю (отсутствие шифрования)

    • CID указывает на поток, для которого запрашивается полоса восходящего канала (uplink).

    • Поле запроса полосы BR определяет запрашиваемых байт.

    • Допустимыми типами для запросов полосы являются 000000 для инкрементации и 000001 для агрегатирования.

    Рис. 3. Формат заголовка запроса полосы

    Поля заголовка запроса полосы определены в таблице. Каждый заголовок кодируются, начиная с полей НТ и ЕС. Кодирование этих полей устроено так, что первый байт МАС-заголовка никогда не должен содержать кода 0xFX.

    Таблица 5. Поля заголовка запроса полосы

    Имя поля

    Длина в битах

    Описание

    BR

    16

    Запрос полосы
    Число байтов запрашиваемой SS полосы восходящего канала. Запрос относится к данному CID.

    CID

    16

    Идентификатор соединения

    EC

    1

    Всегда равно нулю

    HCS

    8

    8-битовая контрольная сумма заголовка. Образующий полином: g(D)=D8+D2+D+1.

    HT

    1

    HT = 1.

    Тип

    6

    Поле указывает на тип заголовка запроса полосы

    Могут присутствовать три типа подзаголовков МАС (фрагментации и управления). Если подзаголовки фрагментации и управления присутствуют одновременно, то подзаголовок управления помещается первым. Подзаголовки упаковки и фрагментации несовместимы.

    Структура подзаголовка фрагментации (FSH) представлена в таблице 6.

    Таблица 6. Структура подзаголовка фрагментации (FSH)

    Синтаксис

    Размер

    Описание

    Подзаголовок фрагментации() {

     

     

    FC

    2 бита

     

    FCN

    3 бита

     

    Зарезервировано для использования с CS

    3 бита

     

    }

     

     

    Поля подзаголовка фрагментации описано в таблице 7.

    Таблица 7. Поля подзаголовка фрагментации

    Имя поля

    Длина в битах

    Описание

    FC

    2

    Управление фрагментацией
    Индицирует состояние поля данных (PDU):
    00 = фрагментации нет
    01 = последний фрагмент
    10 = первый фрагмент
    11 = промежуточный фрагмент

    FCN

    3

    Порядковый номер фрагмента
    Определяет порядковый номер текущего фрагмента SDU. Это поле увеличивается на 1 (по модулю 8) для каждого фрагмента, включая не фрагментированные SDU.

    Подзаголовок управления GM (Grand Management) содержит два байта и используется SS, чтобы реализовать управление полосой, необходимой BS. Структура подзаголовка управления представлена в таблице 8.

    Таблица 8. Структура подзаголовка управления

    Синтаксис

    Размер

    Описание

    Подзаголовок Grant Management () {

     

     

    if(тип службы диспетчеризации = UGS) {

     

     

    SI

    1 бит

     

    PM

    1 бит

     

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

    14 бит

    Устанавливается равным 0

    }

     

     

    else {Комбинированный запрос}

    16 бит

     

    }

     

     

    Описание полей подзаголовка управления представлено в табл. 9.

    Таблица 9. Описание полей подзаголовка управления

    Имя поля

    Длина в битах

    Описание

    PBR

    16

    Комбинированный запрос

    Число байт, запрошенных SS для полосы восходящего канала. Запрос полосы относится к CID и не включает поля заголовка физического уровня.

    PM

    1

    Регистрация (poll-me)
    0 = никаких действий
    1 = используется SS для запроса регистрации полосы.

    CI

    1

    Индикатор смещения (slip)
    0 = никаких действий
    1 = используется SS для указания смещения возможностей восходящего канала по отношению к длине очереди в этом канале.

    Когда используется упаковка, МАС разрешает упаковать несколько SDU в один блок MAC PDU. При упаковке нескольких MAC SDU различной длины, каждый из них снабжается своим подзаголовком упаковки. Формат подзаголовка упаковки описан в табл. 10.

    Таблица 10. Формат подзаголовка упаковки

    Синтаксис

    Размер

    Описание

    Подзаголовок упаковки () {

     

     

    FC

    2 бита

     

    FSN

    3 бита

     

    Длина

    11 бит

     

    }

     

     

    Описание полей подзаголовка управления представлено в табл.11.

    Таблица 11. Описание полей подзаголовка управления

    Имя поля

    Длина в битах

    Описание

    FC

    2

    Управление фрагментацией
    Указывает состояние фрагментации поля данных:
    00 = без фрагментации
    01 = последний фрагмент
    10 = первый фрагмент
    11 = промежуточный фрагмент

    FSN

    3

    Порядковый номер фрагмента
    Определяет номер фрагмента SDU. Это поле увеличивается на 1 (по модулю 8) для каждого фрагмента.

    Длина

    11

    Длина в байтах MAC SDU или SDU фрагмента, включая двухбайтовый подзаголовок упаковки.

    2. Сообщения управления МАС

    Определен набор управляющих сообщений МАС. Эти сообщения транспортируются в блоках данных MAC PDU. Все управляющие сообщения МАС начинаются с поля тип сообщения и могут содержать дополнительные поля. Управляющие сообщения для базовых, широковещательных и исходных соединений (initial ranging) не могут быть фрагментированы или упакованы. Управляющие сообщения первичного соединения могут быть упакованы и/или фрагментированы. Значения поля тип сообщения представлены в табл. 12. Управляющие сообщения не могут передаваться через транспортные соединения.

    Таблица 12. Значения поля тип

    Тип

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

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

    Соединение

    0

    UCD

    Дескриптор восходящего канала

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

    1

    DCD

    Дескриптор нисходящего канала

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

    2

    DL-MAP

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

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

    3

    UL-MAP

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

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

    4

    RNG-REQ

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

    Исходное или базовое

    5

    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

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

    Базовое

    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-255

     

    Зарезервировано на будущее

     

    3. Сообщение дескриптора нисходящего канала (DCD)

    DCD периодически передается BS, чтобы определить характеристики физического нисходящего канала. Параметры, следующие за ID канала, и число изменений конфигурации представляются в формате TLV, где поля типа и длины имеют длину один байт. Формат сообщения DCD описан в табл. 13.

    Таблица 13. Формат сообщения DCD

    Синтаксис

    Размер

    Описание

    DCD_Message_Format () {

     

     

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

    8 бит

     

    Идентификатор нисходящего канала

    8 бит

     

    Число изменений конфигурации

    8 бит

     

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

    перем.

     

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

     

     

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

     

    Для каждого профиля нисходящего канала с 1 до n

    Downlink_Burst_Profile}

     

    Зависит от PHY

    } }

     

     

    BS сформирует DCD в формате табл. 13, включая все перечисленные ниже параметры:

    Число изменений конфигураций

    Инкрементируется BS на 1 по модулю 256 для любого изменения параметра канала с заданным дескриптором. Если значение этого счетчика в последующем DCD остается тем же, SS может решить, что остальные поля не изменились и игнорировать оставшуюся часть сообщения.

    Идентификатор нисходящего канала

    Идентификатор нисходящего канала, к которому относится сообщение. Этот идентификатор произвольно выбирается BS и является уникальным для заданного домена подуровня MAC.

    Параметры сообщения, которые следуют за числом изменений конфигурации, кодируются в формате TLV.

    Downlink_Burst_Profile имеет комбинированную кодировку TLV, которая сопряжена с DIUC (Downlink Interval Usage Code) используемого физического канала. Каждый Downlink_Burst_Profile представляет собой неупорядоченный список атрибутов PHY, закодированных в формате TLV. Каждому интервалу с помощью сообщения DL-MAP ставится в соответствие DIUC.

    Каждый Downlink_Burst_Profile в сообщении DCD содержит следующие параметры:

    • Тип модуляции

    • Тип кода FEC

    • Длина последнего кода

    • Порог обязательного выхода DIUC

    • Порог минимальной записи DIUC

    • Присутствие преамбулы

    Если тип кода FEC равен 1, 2 или 3 Downlink_Burst_Profile будет содержать также

    • RS байты данных (К)

    • RS байты четности (R)

    Если тип кода FEC равен 2, то Downlink_Burst_Profile будет содержать тип кода BCC. Если же тип кода FEC равен 4, то Downlink_Burst_Profile будет содержать тип кода ряда BTC, тип кода колонки и тип интерливинга BTC.


    Соответствие между профайлом кластера и DUIC представлено в табл. 14.

    Таблица 14. Соответствие между профайлом кластера и DIUC

    Профайл кластера (burst)

    DIUC

    Профайл DL 1

    0

    Профайл DL 2

    1

    Профайл DL 3

    2

    Профайл DL 4

    3

    Профайл DL 5

    4

    Профайл DL 6

    5

    Профайл DL 7

    6

    Профайл DL 8

    7

    Профайл DL 9

    8

    Профайл DL 10

    9

    Профайл DL 11

    10

    Профайл DL 12

    11

    Профайл DL 13

    12

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

    13

    Зазор (Gap)

    14

    Конец таблицы DL-MAP

    15

    Конец таблицы DL-MAP указывает на первый PS после конца DL-субкадра. В табл. 15 представлен формат Downlink_Burst_Profile, который используется в сообщении DCD. Профайл кодируется с типом =1, 8-битовой длиной и 4-битовым DIUC.

    Таблица 15. Формат Downlink_Burst_Profile

    Синтаксис

    Размер

    Описание

    Тип=1

    8 бит

     

    Длина

    перем.

     

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

    4 бита

    Следует устанавливать в 0

    DUIC

    4 бита

     

    Информация в формате TLV

    перем.

     

    Секции данных нисходящего канала используются для передачи информационных и управляющих сообщений для станций клиентов. Для данных всегда используется FEC-кодирование. В режиме TDM данные передаются в порядке понижения трудоемкости профайлов. В случае режима TDMA данные группируются в кластеры (burst). Сообщение DL-MAP содержит карту соответствия, которая уведомляет, с какого PS начинаются изменения профайла. Если в пределах кластера данные (DL) не заполняют всего субкадра, передатчик прекращает работу.

    Вообще число PS i, выделенное для конкретного кластера, может быть вычислено на основе DL-MAP. Пусть n - минимальное число PS, необходимое для одного кодового слова FEC данного профайла. Тогда i=kn+j+q, где k - число кодов FEC, которые относятся к данному кластеру, j - число PS, занятых наибольшим возможным укороченным кодовым словом, а q (0#q<1) равно числу PS, занимаемых заполнителем в конце кластера, чтобы гарантировать целое i. Для операций с фиксированными кодами j=0. В конце кластера (когда нет следующего кодового слова) добавляются 4q символа, чтобы завершить PS. На рис. 4 показана схема привязки DL-MAP для варианта TDM, а на рис. 5 то же для варианта TDMA.


    Рис. 4. Схема привязки DL-MAP, использующая укороченные блоки FEC - вариант TDM

    Рис. 5. Схема привязки DL-MAP, использующая укороченные блоки FEC - вариант TDMA

    Поле данных для нисходящего канала разбивается на блоки, размер которых согласуется с размером кодов после добавления указателя CS. Заметим, что длина поля данных может варьироваться в зависимости от того разрешено ли использование укороченных кодов в профайле кластера. К каждому сегменту поля данных добавляется байт указателя. Это показано на рис. 6.

    Рис. 6. Формат PDU при передаче по нисходящему каналу CS

    Поле указателя определяет номер байта в пакете, который указывает либо на начало первого MAC PDU в пакете, либо на начало любого набора байт, который предшествует следующему MAC PDU. Если в CS-пакете нет MAC PDU или набора байт, тогда байт указателя устанавливается равным нулю. Когда имеются данные для передачи, stuff_byte равный 0xFF будет использоваться в пределах поля данных для заполнения любых ниш между MAC PDU.

    Кодирование и модуляция на физическом уровне нисходящего канала для данного режима отражены на рис. 7.

    Рис. 7. Блок-схема подуровня PMD нисходящего канала

    Нисходящий канал поддерживает адаптивное формирование профайлов кластеров для пользовательской части данных кадра. Может быть определено до 12 профайлов кластера. Параметры каждого передаются SS через МАС-сообщения в управляющей части нисходящего кадра. Использование DIUC определено в табл. 16.

    Таблица 16. Значения DIUC

    DIUC

    Назначение

    0

    Управление кадром (не в сообщениях DCD)

    1-6

    Профайлы кластеров TMD (без преамбулы)

    7-12

    Профайлы кластеров TMDA (фиксированная преамбула)

    13

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

    14

    Зазор (в сообщениях DCD)

    15

    Конец таблицы соответствия

    Так как модуляция и схема FEC могут быть для SS опционными, для BS предусмотрены механизмы идентификации возможностей SS. Эта информация передается от SS к BS при регистрации.

    4. Сообщение привязки нисходящего канала (DL-MAP)

    Сообщение DL-MAP определяет доступ к информации о нисходящем канале. Если длина сообщения не равна целому числу байтов, значение поля LEN в заголовке МАС округляется до ближайшего целого. Формат сообщения DL-MAP описан в табл. 17. Сообщение содержит следующие параметры:

    Синхронизация PHY

    Поле синхронизации PHY зависит от спецификации физического канала.

    Счетчик DCD

    Соответствует числу изменений конфигурации DCD.

    Идентификатор BS

    Идентификатор базовой станции представляет собой 48-битовый код, однозначно определяющий BS. Старшие 24 бита являются идентификатором оператора.

    Число элементов

    Число последующих информационных элементов

    Кодирование остальной части DL-MAP зависит от спецификации PHY, эта часть может и отсутствовать.

    Таблица 17. Формат сообщения DL-MAP

    Синтаксис

    Размер

    Описание

    DL-MAP_Message_Format() {

     

     

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

    8 бит

     

    Поле синхронизации PHY

    перем.

     

    Счетчик DCD

    8 бит

     

    Идентификатор BS

    48 бит

     

    Число элементов DL-MAP n

    16 бит

     

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

     

     

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

     

    Для каждого элемента DL-MAP с 1 до n

    DL-MAP_Information_Element()

    перем.

     

    if!(граница байта) {

     

     

    4 бита заполнителя }

     

    До границы байта

    } } }

     

     

    5. Сообщение дескриптора восходящего канала

    Дескриптор восходящего канала (UCD) периодически передается BS, для того чтобы определить характеристики физического восходящего канала. Отдельное сообщение UCD передается для каждого восходящего канала. BS передает сообщения UCD в формате, показанном в таблице 18. Сообщение содержит следующие параметры:

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

    Увеличивается BS на 1 (по модулю 256), всякий раз, когда производится изменение любого параметра канала с данным дескриптором. Если значение счетчика для очередного UCD остается тем же, SS решает, что остальные поля не изменены и можно игнорировать оставшуюся часть сообщения.

    Размер минидомена

    Размер n минидоменов для восходящего канала в единицах физических доменов. Допустимыми значениями являются n=2m, где m равно целому из диапазона 0-7.

    Идентификатор восходящего канала

    Идентификатор канала, к которому относится сообщение. Идентификатор произвольно выбирается BS и является уникальным в пределах домена субуровня MAC.

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

    Размер исходного окна отсрочки для исходного соперничества за диапазон, выраженный через степень 2. Значение n может лежать в интервале 0-15 (старшие биты могут не использоваться и приравниваться нулю).

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

    Размер конечного окна отсрочки передачи для исходного соперничества за диапазон, выраженный через степень 2. Значение n может лежать в интервале 0-15 (старшие биты могут не использоваться и приравниваться нулю).

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

    Запрос размера исходного окна отсрочки для данных исходного соперничества за диапазон, выраженный через степень 2. Значение n может лежать в интервале 0-15 (старшие биты могут не использоваться и приравниваться нулю).

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

    Запрос размера конечного окна отсрочки передачи для исходного соперничества за диапазон, выраженный через степень 2. Значение n может лежать в интервале 0-15 (старшие биты могут не использоваться и приравниваться нулю).

    Таблица 18. Формат сообщения UCD

    Синтаксис

    Размер

    Описание

    UCD_Message_Format () {

     

     

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

    8 бит

     

    Идентификатор восходящего канала

    8 бит

     

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

    8 бит

     

    Размер минидомена (minislot)

    8 бит

     

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

    8 бит

     

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

    8 бит

     

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

    8 бит

     

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

    8 бит

     

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

    перем.

     

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

     

     

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

     

    Для каждого профиля восходящего канала с 1 до n

    Uplink_Burst_Profile }

    перем.

     

    } }

     

     

    Чтобы обеспечить гибкость, остальные параметры сообщения кодируются в формате TLV.

    Uplink_Burst_Profile имеет комбинированную кодировку TLV, которая сопряжена с UIUC (Uplink Interval Usage Code) используемого физического канала. Каждый Uplink_Burst_Profile представляет собой неупорядоченный список атрибутов PHY, закодированных в формате TLV. Каждому интервалу с помощью сообщения UL-MAP ставится в соответствие UIUC.

    6. Сообщение привязки восходящего канала(UL-MAP)

    Структура сообщения UL-MAP описана в табл. 19.

    Таблица 19. Структура сообщения UL-MAP

    Синтаксис

    Размер

    Описание

    UL-MAP_Message_Format () {

     

     

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

    8 бит

     

    Идентификатор восходящего канала

    8 бит

     

    Счетчик UCD

    8 бит

     

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

    8 бит

     

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

    32 бита

     

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

     

     

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

     

    Для каждого элемента UL-MAP с 1 до n

    UL-MAP_Information_Element() }

    перем.

     

    } }

     

     

    BS генерирует сообщение UL- MAP со следующими параметрами:

    Идентификатор восходящего канала

    Идентификатор восходящего канала, к которому относится сообщение

    Счетчик UCD

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

    Число элементов

    Число информационных элементов привязки

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

    Эффективное время начала предоставления ресурсов согласно UL-MAP в минидоменах.

    Информационные элементы привязки (map)

    Каждый информационный элемент (IE) содержит как минимум три следующие поля:

    1. Идентификатор соединения (CID)

    2. Код используемого интервала восходящего канала (UIUC)

    3. Смещение

    Элементы IE определяют выделенные ресурсы полосы для восходящего канала. Каждое сообщение UL-MAP содержит по крайне мере один IE, который отмечает конец последнего выделенного кластера (burst). Элементы IE размещаются в UL-MAP в хронологическом порядке.

    CID определяет соответствие этих элементов уникастному, мультикастному или широковещательному адресу. В зависимости от типа адресации при выделении полосы CID будет базовым CID SS, или транспортным CID для одного из соединений SS. UIUC используется, чтобы определить тип доступа к восходящему каналу и профайл, сопряженный с этим каналом. Uplink_Burst_Profile будет включен в UCD для каждого UIUC, подлежащего использованию в UL-MAP.

    7. Сообщение запроса диапазона (RNG-REQ)

    Запрос RNG-REQ передается SS при инициализации и периодически по запросу BS, чтобы определить сетевую задержку и запросить мощность и/или изменение профайла нисходящего канала. Формат сообщения RNG-REQ описан в табл. 20.

    Таблица 20. Формат сообщения RNG-REQ

    Синтаксис

    Размер

    Описание

    RNG-REQ_Message_Format() {

     

     

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

    8 бит

     

    Идентификатор нисходящего канала

    8 бит

     

    Ожидание до завершения

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    Поле CID в заголовке МАС предполагает наличие следующих значений в случае отправки в период управления инициализации.

    1. CID исходного диапазона, если SS осуществляется попытка подключения к сети.

    2. CID исходного диапазона, если SS еще не зарегистрирована и изменяет восходящий канал (или оба канала) согласно загруженному конфигурационному файлу.

    3. Базовый CID (присвоенный ранее посредством RNG-RSP), если SS еще не зарегистрирована и изменяет восходящий канал согласно загруженному конфигурационному файлу.

    4. Базовый CID (присвоенный ранее посредством RNG-RSP), если SS зарегистрирована и изменяет восходящий канал.

    5. Во всех прочих случаях используется базовый CID, как только он присвоен в сообщении RNG-RSP.

    При посылке в период управления станции CID всегда равен базовому CID. Ниже описаны параметры, присутствующие в сообщении RNG-REQ. Заметим, что длина сообщения RNG-REQ, посланного в период управления инициализацией является фиксированной.

    Идентификатор нисходящего канала

    Идентификатор нисходящего канала, для которого SS получил UCD, описывающий восходящий канал, по которому должен быть передано сообщение запроса диапазона. Это поле содержит 8 бит.

    Ожидание до завершения

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

    Сообщение RNG-REQ должно содержать следующие параметры:

    Запрошенный профайл кластера нисходящего канала

    МАС-адрес SS

    Аномалии рабочего диапазона

    8. Сообщение отклика на запрос диапазона (RNG-RSP)

    Сообщение RNG-RSP передается BS в ответ на полученный запрос RNG-REQ или при необходимости скорректировать параметры канала по результатам измерения, которые были сделаны для других полученных данных или МАС-сообщений. SS готова получать сообщения RNG-RSP в любое время, а не только в ответ на RNG-REQ.

    Исходное сообщение RNG-RSP должно передаваться, с использованием профайла нисходящего канала, который приемлем для обеспечения надежного приема. Для достижения гибкости параметры сообщения, следующие после ID восходящего канала, следует кодировать в формате TLV.

    BS генерирует сообщения RNG-RSP в формате, показанном в табл. 21.

    Таблица 21. Формат сообщения RNG-RSP

    Синтаксис

    Размер

    Описание

    RNG-RSP_Message_Format () {

     

     

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

    8 бит

     

    Идентификатор восходящего канала

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    В сообщение RNG-RSP следует включить следующие параметры:

    Информация подстройки синхронизации

    Информация подстройки мощности

    Информация подстройки частоты

    Состояние диапазона

    Следующие параметры могут быть включены в сообщение RNG-RSP:

    Новое значение частоты нисходящего канала

    Новое значение ID восходящего канала

    Рабочий профайл нисходящего канала

    Базовый CID

    Обязательный параметр, если сообщение RNG-RSP послано на фазе инициализации в ответ на сообщение RNG-REQ.

    CID первичного управления

    Обязательный параметр, если сообщение RNG-RSP послано на фазе инициализации в ответ на сообщение RNG-REQ.

    MAC-адрес SS (48 бит)

    Обязательный параметр, когда CID в МАС-заголовке равен исходному CID диапазона.

    9. Сообщение запроса регистрации (REG-REQ)

    Сообщение REG-REQ посылается SS при инициализации, формат этого запроса описан в таблице 22.

    Таблица 22. Формат сообщения REG-REQ

    Синтаксис

    Размер

    Описание

    REG- REQ_Message_Format() {

     

     

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

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     


    Сообщение REG-REQ включает в себя следующие параметры:

    CID первичного управления (в общем МАС-заголовке)

    Для SS CID в общем МАС-заголовке является CID первичного управления.

    Все остальные параметры кодируются в формате TLV.

    Сообщение REG-REQ содержит в себе следующие TLV:

    Последовательность HMAC

    CID поддержки восходящего канала

    Сообщение REG-REQ может содержать следующие параметры TLV, формируемые SS:

    Код ID производителя (SS)

    Код возможностей SS

    10. Сообщение отклика регистрации REG-RSP

    Сообщение REG-RSP посылается BS в ответ на запрос REG-REQ, формат этого запроса описан в таблице 23.

    Таблица 23. Формат сообщения REG-RSP

    Синтаксис

    Размер

    Описание

    REG-RSP_Message_Format () {

     

     

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

    8 бит

     

    Отклик

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    BS генерирует REG-RSP, которые содержат в себе следующие параметры:

    CID (в общем заголовке МАС)

    CID является в общем заголовке МАС является CID первичного управления для данной SS.

    Отклик

    Однобайтовый код, принимающий значение:

    0 = ok

    1 = неудача аутентификации сообщения

    В сообщения REG-RSP включаются следующие параметры:

    Версия МАС

    Вторичный CID управления

    Последовательность (HMAC) кода аутентификации хэшированного сообщения

    Следующие параметры включаются в сообщение REG-RSP, если были обнаружены в REG-REQ или BS требует использования нестандартного значения параметра:

    Возможности SS

    BS откликается на возможности SS (только если они это отражено в REG-REQ). BS откликается на возможности SS для того чтобы уведомить о возможности их использования. Если BS не распознает возможность SS, она возвращает “off” в сообщении REG-RSP.

    Возможности возвращенные в REG-RSP не будут установлены на уровне выше, чем это указано в REG-REQ.

    Следующие параметры могут быть включены в REG-RSP:

    Расширения, специфические для производителя.

    11. Сообщения управления ключами конфиденциальности (PKM-REQ/PKM-RSP)

    Управление ключами конфиденциальности (PKM) использует два типа ключей, запрос PKM (PKM-REQ) и отклик PKM (PKM-RSP), как это видно из табл. 24.

    Таблица 24. Формат сообщения PKM-REQ/PKM- RSP

    Значение типа

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

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

    9

    PKM-REQ

    Управляющий запрос ключа конфиденциальности [SS -> BS]

    10

    PKM-RSP

    Отклик на запрос ключа конфиденциальности [SS -> BS]

    Только одно сообщение PKM вкладывается в поле данных управляющего сообщения МАС. Протокольные сообщения PKM передаются от SS к BS с использованием формата, описанного в табл. 25. Они передаются SS в рамках первичной фазы управляющего соединения.

    Таблица 25. Формат протокольных сообщений PKM

    Синтаксис

    Размер

    Описание

    PKM-REQ_Message_Format() {

     

     

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

    8 бит

     

    Код

    8 бит

     

    Идентификатор PKM

    8 бит

     

    Атрибуты, закодированные в форме TLV

    перем.

     

    }

     

     

    Протокольные сообщения PKM передаются от BS к SS с использованием формата, описанного в табл. 26. Они передаются SS в рамках первичной фазы управляющего соединения.

    Таблица 26. Формат сообщения PKM

    Синтаксис

    Размер

    Описание

    PKM-RSP_Message_Format () {

     

     

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

    8 бит

     

    Код

    8 бит

     

    Идентификатор PKM

    8 бит

     

    Атрибуты, закодированные в форме TLV

    перем.

     

    }

     

     

    Параметрами этих сообщений являются:

    Код

    Код содержит один октет и идентифицирует тип РКМ-пакета. Когда пакет приходит с неверным кодом, он молча отбрасывается. Значения кода определены в табл 27.

    Идентификатор PKM

    Поле идентификатора содержит один октет. SS использует идентификатор при реагировании на запрос BS. SS инкрементирует поле идентификатора (по модулю 256) при отправке очередного (нового) РКМ-сообщения. Новым сообщением может быть запрос аутентификации или запрос ключа, которые не являются повторами передачи при таймауте. Поле идентификатора в информационных сообщениях аутентификации, которые не предполагаю последующих откликов, устанавливается равным нулю.

    Поле идентификатора в сообщении BS PKM-RSP должно соответствовать значению идентификатора из PKM-REQ, на которое BS реагирует. Поле идентификатора в сообщении ключа шифрования трафика (ТЕК), которое не посылается в ответ на PKM-REQ, следует устанавливать равным нулю.

    При получении сообщения PKM-RSP SS ассоциирует сообщение с определенной машиной состояния (например, машиной состояния авторизации в случае отклика авторизации).

    SS отслеживает идентификатор своего последнего отложенного запроса авторизации. SS отбрасывает отклики авторизации и отказы авторизации с полями идентификатора, которые не соответствуют заданному отложенному запросу авторизации.

    SS отслеживает также идентификатор своего последнего отложенного запроса ключа для каждой ассоциации безопасности (SA). SS отбросит сообщение KEY Reply и Key Reject с не соответствующими запросу значениями идентификатора.

    Атрибуты

    PKM-атрибуты несут в себе данные, специфические для обменов аутентификации, авторизации или управления ключами между клиентом и сервером. Каждый тип PKM-пакета имеет свой собственный набор необходимых и опционных атрибутов. Если не указано явно, порядок атрибутов в сообщении произволен. Конец списка атрибутов определяется полем LEN заголовка МАС PDU.

    Таблица 27. Коды сообщений

    Код

    Тип PKM-сообщения

    Имя управляющего сообщения МАС

    0-2

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

    -

    3

    SA Add

    PKM-RSP

    4

    Auth Request

    PKM-REQ

    5

    Auth Reply

    PKM-RSP

    6

    Auth Reject

    PKM-RSP

    7

    Key Request

    PKM-REQ

    8

    Key Reply

    PKM-RSP

    9

    Key Reject

    PKM-RSP

    10

    Auth Invalid

    PKM-RSP

    11

    TEK Invalid

    PKM-RSP

    12

    Authent Info

    PKM-REQ

    13-255

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

    -

    BS и SS молча отбрасывает запросы/отклики, которые не содержат полного списка необходимых атрибутов.

    12. Сообщение добавления ассоциации безопасности (SA Add)

    Это сообщение посылается BS -> SS для установления одной или более дополнительных SA. Код =3, атрибуты представлены в табл. 28.

    Таблица 28. Формат сообщения SA Add

    Атрибут

    Содержимое

    Порядковый номер ключа

    Порядковый номер ключа авторизации

    (один или более) дескрипторов SA

    Каждый составной атрибут SA-дескриптора специфицирует идентификатор ассоциации SAID и дополнительные свойства SA

    13. Сообщение запроса авторизации (Auth Request)

    Код = 4

    Атрибуты перечислены в табл. 29.

    Таблица 29. Атрибуты сообщения Auth Request

    Атрибут

    Содержимое

    SS-сертификат

    Содержит сертификат Х.509 SS

    Возможности безопасности

    Описывает запрашиваемые возможности безопасности SS

    SAID

    Первичный SAID для SS, равный базовому CID

    Атрибут возможностей безопасности является составным атрибутом, описывающим запрашиваемые SS требования безопасности.

    Атрибут SAID содержит SAID конфиденциальности. В этом случае предоставляемый SAID равен базовому CID SS.

    14. Сообщение отклика авторизации (Auth Reply)

    Отклик авторизации посылается BS клиенту SS в ответ на запрос авторизации, и содержит ключ авторизации, время жизни ключа и список дескрипторов SA, идентифицирующие первичный и статический SA. Эти данные определяют параметры доступа SS (тип, криптографический набор и т.д.). Ключ авторизации шифруется открытым ключом SS. Список дескрипторов SA включает в себя дескриптор для базового CID , сообщенный BS в соответствующем Auth Request. Этот список может содержать также дескрипторы статических SAID, к которым разрешен доступ SS.

    Код = 5

    Атрибуты сообщения Auth Reply представлены в табл. 30.

    Таблица 30. Атрибуты сообщения Auth Reply

    Атрибут

    Содержимое

    Auth-Key

    Ключ авторизации, зашифрованный общедоступным ключом клиента SS

    Время жизни ключа

    Время активной жизни ключа

    Порядковый номер ключа

    Порядковый номер ключа авторизации

    Один или более дескрипторов SA

    Каждый составной атрибут дескриптора SA специфицирует SAID и дополнительные свойства SA

    15. Сообщение отклонения авторизации (Auth Reject)

    BS реагирует на запрос авторизации SS, посылая сообщение Auth Reject, если базовая станция отклонила попытку авторизации SS.

    Код = 6

    Атрибуты сообщения Auth Reject представлены в табл. 31.

    Таблица 31.Атрибуты сообщения Auth Reject

    Атрибут

    Содержимое

    Код ошибки

    Код ошибки, указывающий на причину отказа авторизации

    Опционная отображаемая строка

    Текстовая строка, поясняющая причину отклонения авторизации

    16. Сообщение запроса ключа

    Код = 7

    Атрибуты сообщения запроса ключа представлены в табл. 32.

    Таблица 32. Атрибуты сообщения запроса ключа

    Атрибут

    Содержимое

    Порядковый номер ключа

    Порядковый номер ключа авторизации

    SAID

    ID ассоциации безопасности

    Дайджест HMAC

    Дайджест ключевого сообщения, полученный методом SHA

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

    17. Сообщение отклика на запрос ключа

    Код = 8

    Атрибуты сообщения отклика на запрос ключа представлены в табл. 33.

    Таблица 33. Атрибуты сообщения отклика на запрос ключа

    Атрибут

    Содержимое

    Порядковый номер ключа

    Порядковый номер ключа авторизации

    SAID

    ID ассоциации безопасности

    TEK-параметры

    Предшествующее поколение параметров ключа, соответствующих SAID

    TEK-параметры

    Новое поколение параметров ключа, соответствующих SAID

    Дайджест HMAC

    Дайджест ключевого сообщения, полученный методом SHA

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

    В любой момент времени BS поддерживает два набора активных поколений ключевого материала для каждого SAID. Один набор соответствует “старому”, второй набор соответствует “новому” поколению ключевого материала. Новое поколение имеет порядковый номер ключа на 1 больше (по модулю 4), чем старое. BS рассылает клиентам SS оба поколения активного ключевого материала. Таким образом, сообщения отклика на запрос ключа содержит два атрибута ТЕК-параметров, каждый из которых содержит ключевой материал для одного из активных наборов ключевого материала SAID.

    Включение дайджеста позволяет клиенту-получателю аутентифици-ровать сообщение ключевого отклика и гарантировать синхронизацию наборов ключей у BS и SS.

    18. Сообщение отклонение ключа

    Получение сообщения отклонения ключа (KeyReject) указывает получившему клиенту SS, что для заданного SAIDавторизация более недействительна.

    Код =9

    Атрибуты сообщения Key Reject представлены в табл. 34.

    Таблица 34. Атрибуты сообщения KeyReject

    Атрибут

    Содержимое

    Порядковый номер ключа

    Порядковый номер ключа авторизации

    SAID

    ID ассоциации безопасности

    Код ошибки

    Код, указывающий причину отклонения запроса ключа

    Текстовая строка (опционна)

    Отображаемая строка, поясняющая отклонение запроса

    Дайджест HMAC

    Дайджест ключевого сообщения, полученный методом SHA

    Атрибут дайджеста должен быть последним в списке атрибутов сообщения.

    19. Сообщение недействительности авторизации

    BS может послать сообщение о недействительности авторизации клиенту SS:

    1. по своей инициативе

    2. как отклик на сообщение, полученное от SS

    В обоих случаях такое сообщение предлагает SS предпринять повторную авторизацию в BS. BS посылает сообщение о недействительности авторизации, если BS не распознает SS в качестве авторизованного объекта, или по причине неудачной верификации дайджеста сообщения, что говорит об утрате синхронизации ключевых наборов BS и SS.

    Код = 10

    Атрибуты сообщения Authorization Invalid представлены в табл. 35.

    Таблица 35. Атрибуты сообщения Authorization Invalid

    Атрибут

    Содержимое

    Код ошибки

    Код, указывающий причину сообщения о недействительности авторизации

    Текстовая строка (опционна)

    Отображаемая строка, поясняющая причину недействительности авторизации

    20. Сообщение TEK Invalid

    BS посылает клиенту (SS) сообщение TEK Invalid, если установлено, что зашифрованное PDU нисходящего канала содержит некорректное значение ТEK в полученном заголовке МАС.

    Код =11

    Атрибуты сообщения TEK Invalid представлены в табл. 36.

    Таблица 36. Атрибуты сообщения TEK Invalid

    Атрибут

    Содержимое

    Порядковый номер ключа

    Порядковый номер ключа авторизации

    SAID

    ID ассоциации безопасности

    Код ошибки

    Код, указывающий причину сообщения TEK Invalid

    Текстовая строка (опционна)

    Отображаемая строка, поясняющая причину сообщения TEK Invalid

    Дайджест HMAC

    Дайджест сообщения, полученный методом SHA

    Атрибут дайджеста должен быть последним в списке атрибутов сообщения.

    21. Информационное сообщение аутентификации Authent Info)

    Сообщение Authent Info содержит один атрибут CA-Certificate формата Х.509 производителя SS.

    Код = 12

    Атрибуты сообщения Authent Info представлены в табл. 37.

    Таблица 37. Атрибуты сообщения Authent Info

    Атрибут

    Содержимое

    СА-сертификат

    Сертификат производителя SS

    22. Сообщение запроса динамического добавления сервиса DSA-REQ)

    Сообщение DSA-REQ посылается SS или BS для создания нового сервисного потока. SS или BS генерируют сообщения DSA-REQ в форме, описанной в табл. 38.

    Таблица 38. Формат сообщения DSA-REQ

    Синтаксис

    Размер

    Описание

    DSA-REQ_Message_Format () {

     

     

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

    8 бит

     

    ID транзакции

    16 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    Сообщение содержит следующие параметры:

    CID

    CID первоначального управления SS

    ID транзакции

    Уникальный идентификатор транзакции, присваиваемый отправителем

    Сообщение DSA-REQ может содержать параметры только для одного потока в одном направлении. Это сообщение несет в себе:

    Параметры сервисного потока

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

    Кодировка параметров подуровня конвергенции

    Спецификация специфических для CS параметров потока

    Если активизированы требования конфиденциальности, сообщение DSA -REQ будет содержать:

    Последовательность HMAC

    Атрибут последовательности HMAC включает в себя дайджест сообщения, идентифицирующий отправителя. Этот атрибут является последним в списке.

    23. Динамическое добавление сервиса (DSA), инициируемое SS

    Значения ссылок сервисных потоков являются локальными по отношению к сообщениям DSA; каждому сервисному потоку в рамках RSA-REQ присваивается уникальная ссылка. Это значение не должно быть уникальным с точки зрения других сервисных потоков известных отправителю.

    Инициированный SS RSA-REQ может использовать имя класса сервиса вместо некоторых или всех параметров QoS.

    24. DSA, инициируемое BS

    Инициированный BS RSA-REQ будут также включать CID, уникальный в МАС-домене. Инициированный BS RSA-REQ для именованных классов сервиса будут включать набор параметров QoS, ассоциированный с этим классом сервиса, и дескриптор SA сервисного потока.

    25. Сообщение отклика (DSA-RSP) динамического добавления сервиса

    DSA-RSP генерируются в ответ на полученный запрос DSA-REQ. Формат этого сообщения описан в табл. 39.

    Таблица 39. Формат сообщения DSA-RSP

    Синтаксис

    Размер

    Описание

    DSA-RSP_Message_Format () {

     

     

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

    8 бит

     

    ID транзакции

    16 бит

     

    Код подтверждения

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    Сообщение имеет следующие параметры:

    CID

    CID первичного управления SS

    ID транзакции

    ID транзакции, соответствующий DSA-REQ

    Код подтверждения

    Определенный код подтверждения для DSA-REQ

    Если транзакция успешна, DSA-RSPсодержит следующие параметры:

    Параметры сервисного потока

    Полная спецификация сервисного потока включается в DSA-RSP, только если она содержит только что присвоенный CID или расширенное имя класса сервиса.

    Кодирования параметров CS

    Спецификация параметров специфичных для сервисного потока CS.

    Если транзакция потерпела неудачу, DSA-RSP будет содержать:

    Набор ошибок сервисного потока

    Соответствующее сообщение DSA-RSP содержит набор ошибок сервисного потока и ссылку/идентификатор сервисного потока для каждого сервисного потока, потерпевшего неудачу. Каждый набор ошибок сервисного потока будет включать каждый из специфических нереализованных параметров QoS соответствующего сервисного потока. В случае успеха этот параметр отсутствует.

    Если требуется конфиденциальность, сообщение DSA-RSP включает в себя:

    Последовательность HMAC

    Атрибут последовательности HMAC содержит дайджест сообщения (для аутентификации отправителя). Этот атрибут должен быть последним в списке.

    26. DSA, инициированное SS

    Сообщения DSA-RSP, посланные BS, для успешно добавленных сервисных потоков, содержат CID. DSA-RSP для разрешенных или активных наборов параметров QoS также должны содержать CID.

    Сообщения DSA-RSP, посланные BS, будут также содержать SA-дескриптор сервисного потока. Если соответствующий запрос DSA-REQ использует имя класса сервиса в запросе добавления сервиса, DSA-RSP будет содержать набор параметров QoS, ассоциированный с указанным классом сервиса. Если имя класса сервиса используется в DSA-REQ совместно с другими параметрами QoS, BS воспримет или отклонит DSA-REQ, используя набор параметров запроса. Если кодирование сервисного потока конфликтует с атрибутами класса сервис, BS будет использовать параметры, содержащиеся в DSA-REQ. Если транзакция не прошла, BS будет использовать исходную ссылку сервисного потока, чтобы идентифицировать конфликтные параметры в DSA-RSP.

    27. DSA, инициированное BS

    Если транзакция потерпела неудачу, SS будет использовать CID, чтобы идентифицировать конфликтные параметры DSA-RSP.

    28. Сообщение подтверждения для динамического добавления сервиса (DSA-ACK)

    Сообщение DSA-ACK генерируется в ответ на полученный DSA-RSP. Формат этого сообщения описан в табл. 40.

    Таблица 40. Формат сообщения DSA-ACK

    Синтаксис

    Размер

    Описание

    DSA-ACK_Message_Format() {

     

     

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

    8 бит

     

    ID транзакции

    16 бит

     

    Код подтверждения

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    В сообщении используются следующие параметры:

    CID (в общем МАС-заголовке)

    CID первичного управления SS

    ID транзакции

    Идентификатор транзакции из соответствующего DSA-RSP.

    Код подтверждения

    Соответствующий код подтверждения для DSA-RSP.

    Если отклик DSA-RSP содержит ошибки (конфликты параметров), формируется набор ошибок сервисного потока, который помещается в сообщение DSA-ACK.

    29. Сообщение запроса DSC-REQ

    Сообщение DSC-REQ посылается SS или BS, чтобы динамически изменить параметры существующего сервисного потока. Формат DSC-REQ представлен в табл. 41.

    Таблица 41. Формат сообщения DSC-REQ

    Синтаксис

    Размер

    Описание

    DSC-REQ_Message_Format () {

     

     

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

    8 бит

     

    ID транзакции

    116 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    Сообщение DSC-REQ не содержит параметров более чем для одного потока для каждого из направлений передачи (uplink и downlink).

    30. Сообщение отклика динамического изменения сервиса (DSC-RSP)

    Сообщение DSC-RSP генерируется в ответ на полученный запрос DSC-REQ. Формат этого сообщение описан в табл. 42.

    Таблица 42. Формат сообщения DSC-RSP

    Синтаксис

    Размер

    Описание

    DSC-RSP_() {

     

     

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

    8 бит

     

    ID транзакции

    16 бит

     

    Код подтверждения

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    Если транзакция успешна, DSC-RSP может содержать:

    Параметры сервисного потока

    Полная спецификация сервисного потока включается в сообщение DSC-RSP, если она содержит вновь сформированный CID или расширенное имя класса услуг. Если набор параметров сервисного потока содержал принятый набор параметров QoS восходящего потока и этот сервисный поток не имеет ассоциированного CID, DSC-RSP должен включать в себя CID. Если набор параметров сервисного потока содержал имя класса сервиса и принятый набор параметров QoS, DSC-RSP будет включать набор параметров QoS, соответствующий этому классу. Если специфические параметры QoS были включены в запрос сервисного потока заданного класса, эти параметры будут включены в DSC-RSP вместо QoS-параметров того же класса.

    31. Сообщение подтверждения для динамического изменения сервиса (DSC-ACK)

    Сообщение DSC-ACK генерируется в ответ на полученный DSC-RSP и имеет формат, представленный в табл. 43.

    Таблица 43. Формат сообщение DSC-ACK

    Синтаксис

    Размер

    Описание

    DSC-ACK_Message_Format() {

     

     

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

    8 бит

     

    ID транзакции

    16 бит

     

    Код подтверждения

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    Если отклик DSA-RSP содержит ошибки (конфликты параметров), DSC-ACK несет в себе идентификаторы сервисов DSC-RSP, потерпевших неудачу.

    32. Сообщение запроса динамического аннулирования сервиса (DSD-REQ)

    Сообщение DSD-REQ посылается SS или BS, чтобы аннулировать существующий сервисный поток. Формат сообщения описан в табл. 44.

    Таблица 44. Формаи сообщения DSD-REQ

    Синтаксис

    Размер

    Описание

    DSD-REQ_ Message_Format () {

     

     

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

    8 бит

     

    ID транзакции

    16 бит

     

    ID сервисного потока

    32 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    ID сервисного потока

    SFID, который следует аннулировать.

    33. Сообщение отклика на запрос динамического аннулирования сервиса (DSD-RSP)

    Сообщение DSD-RSP генерируется в ответ на полученный запрос DSD-REQ. Формат сообщения представлен в табл. 45.

    Таблица 45. Формат сообщения DSD-RSP

    Синтаксис

    Размер

    Описание

    MCA-REQ_Message_Format() {

     

     

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

    8 бит

     

    ID транзакции

    16 бит

     

    Код подтверждения

    8 бит

     

    ID сервисного потока

    32 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    ID сервисного потока

    SFID из DSD-REQ, к которому относится подтверждение.

    34. Сообщение запроса включения/удаления из списка мультикастного запроса (MCA-REQ)

    Сообщение MCA-REQ посылается SS, чтобы включить или исключить его из списка группы мульткастной рассылки. Формат сообщения представлен в табл. 46.

    Таблица 46. Формат сообщения MCA-REQ

    Синтаксис

    Размер

    Описание

    MCA-REQ_Message_Format() {

     

     

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

    8бит

     

    ID транзакции

    16 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    Прочие параметры представляются в форме TLV:

    Мульткастный CID

    Присвоение

    35. Сообщение отклика на запрос включения/удаления из списка мультикастного запроса (MCA-RSP)

    Сообщения посылаются станцией SS в ответ на запрос MCA-REQ. Формат сообщения описан в табл. 47.

    Таблица 47. Формат сообщения MCA-RSP

    Синтаксис

    Размер

    Описание

    MCA-RSP_Message_Format() {

     

     

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

    8 бит

     

    ID транзакции

    16 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    36. Сообщение запроса изменения профайла нисходящего канала (DBPC-REQ)

    Сообщение DBPC-REQ посылается из SS к BS с использованием базового CID SS для запроса изменения профайла нисходящего канала, который используется BS для передачи данных SS. Сообщение DBPC-REQ будет послано с текущим значением типа передачи данных. Если SS была пассивна в течение некоторого времени в восходящем канале и обнаруживает деградацию условий в нисходящем канале, то она использует это сообщение для повышения качества передачи данных. Формат сообщения представлен в табл. 48.

    Таблица 48. Формат сообщения DBPC-REQ

    Синтаксис

    Размер

    Описание

    DBPC-REQ_Message_Format() {

     

     

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

    8бит

     

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

    4 бита

     

    DIUC

    4 бита

     

    }

     

     

    DIUC

    Значения DUIC (Downlink Interval Usage Code) определены в табл. ……

    37. Сообщение отклика на изменение профайла нисходящего канала (DBPC-RSP)

    Сообщение DBPC-RSP посылается BS с привлечением базового CID SS в ответ на запрос DBPC-REQ, посланный SS. Если параметр DIUC совпадает с содержащемся в запросе DBPC-REQ, он воспринимается. В противном случае, если запрос отвергается, параметр DIUC должен быть предыдущим, при котором SS получал данные по нисходящему каналу. Формат сообщения представлен в табл. 49.

    Таблица 49.Формат сообщения DBPC-RSP

    Синтаксис

    Размер

    Описание

    DBPC-REQ_Message_Format() {

     

     

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

    8 бит

     

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

    4 бита

    Для будущего использования

    DIUC

    4 бита

     

    }

     

     

    38. Сообщение команды сброса (RES-CMD)

    Сообщение RES-CMD передается базовой станцией на базовый CID SS, чтобы заставить ее осуществить сброс, повторно инициировать МАС и повторить исходный доступ к системе. Сообщение может быть использовано, если SS не реагирует на команды BS или если BS детектирует ненормальности в восходящем канале до SS. Формат сообщения RES-CMD представлен в табл. 50.

    Таблица 50. Формат сообщения RES-CMD

    Синтаксис

    Размер

    Описание

    DBPC-REQ_Message_Format() {

     

     

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

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    39. Сообщение запроса базовых возможностей SS (SBC-REQ)

    SS посылает сообщение SBC-REQ при инициализации. SS генерирует SBC-REQ согласно схеме, представленной в табл. 51.

    Таблица 51. Формат сообщения SBC-REQ

    Синтаксис

    Размер

    Описание

    SBC-REQ_Message_Format() {

     

     

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

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    40. Сообщение отклика на запрос базовых возможностей (SBC-RSP)

    Для обеспечения гибкости параметры сообщения SBC-RSP кодируются в форме TLV.

    Таблица 52. Формат сообщения SBC-RSP

    Синтаксис

    Размер

    Описание

    SBC-RSP_Message_Format() {

     

     

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

    8 бит

     

    Код подтверждения

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    Определенные параметры должны быть включены в SBC-RSP, если они присутствуют в SS SBC-REQ.

    Поддерживаемые физические параметры

    Поддержка выделения полосы

    BS реагирует на субнабор возможностей SS, присутствующий в SBC-REQ. BS уведомляет, какие из возможностей SS могут быть использованы. Если BS не распознает возможности SS, то возвращает флаг “off”. Только возможности, помеченные “on” в сообщении REG-RSP, могут успешно использоваться.

    41. Сообщение сверки часов (CLK-CMP)

    В сети с сервисными потоками, несущими данные, где требуется реконструирование сигналов часов (напр., DS1 и DS3) базовая станция периодически широковещательно посылает сообщения CLK-CMP. Если это предусмотрено, BS будет генерировать сообщение CLK-CMP с интервалом, определенным согласно формату, описанному в табл. 53.

    Таблица 53. Формат сообщений CLK-CMP

    Синтаксис

    Размер

    Описание

    CLK-CMP_Message_Format() {

     

     

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

    8 бит

     

    Счетчик синхротактов n

    8 бит

     

    for(i=1; i<-n; i++) {

     

     

    Clock ID(i)

    8 бит

     

    Порядковый номер [i]

    8 бит

     

    Результат сравнения[i] }

    8 бит

     

    }

     

     

    Сообщения CLK-CMP включают в себя следующие параметры: ID часов (ClockID), порядковый номер, и результат сравнения показаний часов CCV (Clock Comparison Value).

    Порядковый номер

    8-битовый код, инкрементируемый BS на 1 (по модулю 256) при формировании сообщения CLK-CMP. Этот параметр используется для детектирования потери пакетов.

    Результат сверки часов

    8-битовый код разности (по модулю 256) между следующими двумя эталонными сигналами: (1) 10МГц эталонная частота, синхронизованная с символьными часами радиоканала (например, GPS), и (2) эталонной частотой 8.192 МГц, синхронизованной с сетевыми часами.

    42. Сообщение команды De/Re (DREG-CMD)

    Сообщение DREG-CMD отправляется базовой станцией по базовом CID SS, чтобы изменить ее состояние доступа. По получении DREG-CMD SS выполнит операцию, предписываемую присланным кодом операции. Тип управления МАС для данного сообщения представлен в табл. 54.

    Таблица 54. Формат сообщения DREG-CMD.

    Синтаксис

    Размер

    Описание

    DREG-CMD_Message_Format() {

     

     

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

    8 бит

     

    Код операции

    8 бит

     

    Параметры, закодированные в форме TLV

    перем.

     

    }

     

     

    Коды операции и их значения представлены в табл. 55.

    Таблица 55. Коды операций

    Код операции

    Операция

    0х00

    SS уходит с этого канала и пытается перейти на другой

    0х01

    SS прослушивает текущий канал, но не передает, пока не получит сообщение RES-CMD

    0х02

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

    0х03

    SS возвращается к нормальной работе и может передавать, используя любые активные соединения.

    0х04-0хFF

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

    43. Сообщение о получении DSx (DSX-RVD)

    Сообщение о получении пакетов динамических сервисов (DS) генерируется базовой станцией в ответ на первичный запрос DSx-REQ со стороны SS, чтобы проинформировать SS о том, что BS получила сообщение DSx-REQ в более приемлемое время, чем это может быть сделано с помощью DSx-RSP, которое может быть прислано только после DSx-REQ. Формат DSX-RVD представлен в табл. 56.

    Таблица 56. Формат сообщений DSX-RVD

    Синтаксис

    Размер

    Описание

    DSX-RVD_Message_Format() {

     

     

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

    8 бит

     

    ID транзакции

    16 бит

     

    Код подтверждения

    8 бит

     

    }

     

     

    44. Сообщение завершения копирования посредством TFTP конфигурационного файла (TFTP-CPLT)

    Сообщение TFTP-CPLT генерируется SS, когда ей удалось успешно получить конфигурационный файл из сервера. Формат сообщения TFTP-CPLT описан в табл. 57.

    Таблица 57. Формат сообщения TFTP-CPLT

    Синтаксис

    Размер

    Описание

    TFTP-CPLT_Message_Format() {

     

     

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

    8бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    45. Сообщение отклика на уведомление о завершении копирования конфигурационного файла (TFTP-RSP)

    Сообщение TFTP-RSP генерируется базовой станцией BS в ответ на сообщение TFTP-CPLT, присланное SS. Формат сообщения TFTP-RSP описан в таблице 58.

    Таблица 58. Формат сообщения TFTP-RSP

    Синтаксис

    Размер

    Описание

    TFTP-CPLT_Message_Format() {

     

     

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

    8 бит

     

    Данные, закодированные в форме TLV

    перем.

     

    }

     

     

    Несколько МАС-PDU могут быть переданы вместе как по восходящему, так по нисходящему каналу. МАС-PDU управляющих сообщений, пользовательских данных, запросов полосы могут быть пересланы за одну передачу. Схема объединения иллюстрируется на рис. 8.

    Рис. 8. Объединение MAC PDU (каждое из полей имеет свой уникальный CID)

    МАС SDU может быть разделен между одним или более МАС PDU. Это позволяет более эффективно использовать доступную полосу пропускания с учетом требующегося уровня QoS. Фрагментация может быть реализована по инициативе BS или SS. Это определяется на базе формирования соединения. Значения поля FC описаны в табл. 59.

    Таблица 59. Значения поля FC

    Фрагмент

    FC

    FCN

    Первый фрагмент

    10

    Инкрементируется по модулю 8

    Промежуточный фрагмент

    11

    Инкрементируется по модулю 8

    Последний фрагмент

    01

    Инкрементируется по модулю 8

    Нефрагментировано

    00

    Инкрементируется по модулю 8


    Порядковый номер позволяет SS воссоздать исходное поле данных и зарегистрировать потерю любого промежуточного пакета. При потере SS отбрасывает все МАС PDU до тех пор, пока не будет получен новый первый фрагмент или не будет получен нефрагментированный MAC PDU.

    В случае включения режима упаковки, МАС может упаковывать по несколько MAC SDU в один MAC PDU. В режиме упаковки используется атрибут соединения, который говорит о том, используются пакеты постоянной длины или переменной. Схема упаковки для МАС-SDU постоянной длины показана на рис. 9, то же для переменной длины отображено на рис. 10.

    Рис. 9. Упаковка MAC SDU постоянной длины

    Рис. 10. Упаковка MAC SDU переменной длины

    Для улучшения эффективности процесса запрос-предолставление предусмотрен механизм диспетчеризации. Путем задания параметров диспетчеризации и QoS BS может получить требующуюся пропускную способность и время отклика для восходящего канала.

    Базовые виды услуг перечислены в таблице 60, это UGS (Unsolicited Grant Service), сервис запросов реального времени rtPS (Real-Time Polling Service), nrtPS (Non.-REAL-Time Polling Service) и сервис наилучшего возможного BE (Best Effort). Каждый вид сервиса приспособлен для определенного типа потока данных.

    Таблица 60. Сервисы диспетчеризации и правила использования

    Тип диспетче-ризации

    Комбинированный запрос

    Изъятие полосы

    Опрос (polling)

    UGS

    Не разрешен

    Не разрешено

    Для запроса уникастного опроса требуемой полосы для соединения не UGS используется бит PM

    rtPS

    Разрешен

    Разрешено для GPSS

    Диспетчеризация допускает только уникастный опрос

    nrtPS

    Разрешен

    Разрешено для GPSS

    Диспетчеризация может ограничить сервисный поток только уникстным опросом через политику передачи/ запросов; в противном случае разрешены все формы опроса

    BE

    Разрешен

    Разрешено для GPSS

    Разрешены все формы опроса


    Заметим, что каждой SS приписано три CID для целей отправки и получения управляющих сообщений. Используется три соединения, чтобы обеспечить дифференцированные уровни QoS для разных соединений, транспортирующих управляющий трафик МАС. Увеличение или уменьшение требований к полосе необходимо для всех сервисов кроме соединений с постоянной скоростью передачи (например, несжимаемый UGS). Полоса таких соединений не может быть изменена с момента формирования до ликвидации. Требования к сжимаемым UGS, таким как каналированным Т1, могут варьироваться в зависимости от трафика.

    Когда SS нужно запросить полосу для конкретного соединения с ВЕ диспетчеризацией, она посылает сообщение BS, содержащее требование немедленного соединения DAMA (Demand Assigned Multiple Access). QoS соединения определяется в процессе формирования и обеспечивается BS.

    Для получения нужной полосы восходящего канала SS использует запросы, направляемые ею к BS.Так как профайл восходящего канала может меняться динамически, все запросы полосы должны выражаться в байтах, которые необходимы для передачи МАС-заголовка и поля данных, но не должны учитывать издержки физического уровня. Такие запросы могут быть посланы в период запроса IE или любого кластера предоставления данных типа IE.

    В зависимости от характера запроса полосы существует два режима работы SS: GPC (Grant per Connection) и GPSS (Grant per Subscriber Station). В первом случае BS предоставляет полосу конкретно каждому соединению, в то время как во втором случае полоса предоставляется всем соединениям SS. В последнем случае (GPSS) можно использовать меньшую суммарную полосу пропускания, а продвинутая SS может перераспределять полученную от BS полосу. Такой алгоритм удобен для решения задач реального времени, когда требуется более быстрый отклик.

    Опрос (polling) является процессом, с помощью которого базовая станция резервирует SS полосу. Это резервирование может быть для отдельной SS или группы станций. Резервирование для группы соединений и/или SS в действительности определяет информационный элемент (IE) соединения при запросе полосы. Заметим, что опрос осуществляется для соединений или для SS. Полоса всегда запрашивается на основе CID, а резервирование полосы осуществляется для соединения (режим GPC) или для SS (режим GPSS).

    Когда SS опрашиваются индивидуально, никакого сообщения не посылается, просто производится резервирование для SS в восходящем канале, достаточное для реагирования на запросы полосы. Если SS не нуждается в полосе, она возвращает байт 0xFF. Станции SS, работающие в режиме GPSS, при наличии активного UGS-соединения с достаточной полосой, индивидуально опрашиваться не будет, если только они не выставили бит PM (Poll Me) в заголовке пакета UGS-соединения. Это экономит полосу на опросе всех SS.

    Если имеется недостаточная полоса пропускания для индивидуального опроса неактивных SS, некоторые SS могут опрашиваться в составе мультикаст-групп или с привлечением широковещательного опроса Определенные CID зарезервированы для мультикаст-групп и для широковещательных сообщений.

    МАС-протокол поддерживает несколько дуплексных технологий. Выбор дуплексной техники может повлиять на определенные параметры уровня PHY, а также на перечень поддерживаемых возможностей. На МАС-уровне поддерживаются кадровые и бескадровые спецификации PHY. Для бескадрового режима PHY интервала диспетчеризации выбираются МАС. При бескадровой FDD PHY восходящий и нисходящий каналы размещаются на разных частотах, так что каждая SS может осуществлять прием и передачу одновременно. Оба эти канала не используют фиксированной длины кадров. В такой системе нисходящий канал находится всегда во включенном состоянии, и все SS слушают его. Трафик передается широковещательно, используя мультиплексирование по времени (TDM). В восходящем канале применяется режим мультиплексирования TDMA (Time Division Multiple Access).

    В кадровой (кластерной) системе FDD (Frequency Division Duplex) восходящий и нисходящий каналы размещаются на разных частотах, а нисходящие данные передаются в виде кластеров (bursts). Для обоих направлений обмена используются кадры фиксированной длины. Это помогает использовать разные типы модуляции. При этом могут применяться полнодуплексные и полудуплексные SS.

    В режиме TDD (Time Division Duplexing) восходящий и нисходящий каналы используют одну и ту же частоту. TDD-кадр имеет фиксированную длительность и содержат субкадры для восходящего и нисходящего каналов. Кадр делится на целое число физических доменов (PS-slots), которые помогают легко поделить полосу. Работа системы в режиме TDD и структура TDD-кадра показана на рис. 11.

    Рис. 11 Структура TDD кадра

    Синхронизация восходящего канала базируется эталонных временных метках восходящего канала, которые задаются счетчиком, инкрементируемым в 16 раз чаще, чем частота PS. Это позволяет часам SS быть хорошо синхронизованными с BS.

    В случае бескадрового PHY сообщение привязки (DL-MAP) транслирует широковещательно временную метку всем SS. Эта метка BS используется для подстройки часов всех станций клиентов. После того как временная метка BS или SS достигает максимального значения 229-1, она принимает значение нуль и продолжает инкрементироваться.

    Карта резервирования полосы восходящего канала использует в качестве модулей минидомены (minislot). Размер минидомена определяется как число физических доменов PHY PS и содержится в дескрипторе восходящего канала. Один минидомен содержит n PS, где n целое число из интервала 0-255.

    Информация в DL-MAP относится к текущему кадру, то есть к кадру, в котором она доставлена. Информация, доставляемая в UL-MAC, относится к временному интервалу, начинающемуся в момент резервирования (измеряется от начала поученного кадра и до конца последнего зарезервированного минидомена). Пустые IE указывают на паузы в передаче по восходящему каналу. Станции SS не могут осуществлять передачу в это время. Данный вид синхронизации используется как для TDD, так и для FDD. Вариант TDD показан на рис. 12, а вариант FDD на рис. 13.

    Рис. 12. Максимальное время релевантности управляющей информации PHY и MAC (TDD)

    Рис. 13. Максимальное время релевантности управляющей информации PHY и MAC (FDD)

    В бескадровых системах PHY DL-MAP содержит только временные метки восходящего канала и не определяет, какую информацию следует передавать. Все SS постоянно ищут нисходящий сигнал для любого сообщения, которое к ним адресовано. Сообщение UL-MAP содержит временную метку, которая указывает на первый минидомен, который определяет мэпинг. Задержка от конца UL-MAP до начала первого интервала в восходящем канале определенная таблицей соответствия, будет больше максимума RTT плюс время обработки, необходимое SS (см. рис. 14).

    Рис. 14. Временная релевантность UL-MAP информации (бескадровое FDD)

    Возможность передачи определяется наличием свободного минидомена, который может быть использован SS для передачи сообщений или данных. Число возможностей передачи связано с конкретным информационным элементом (IE), размером интервала и объемом передачи.

    BS контролирует восходящий канал с помощью сообщений UL-MAP и определяет, какие из минидоменов являются объектами столкновений. Столкновения могут произойти в периоды установления соединения и при запросах, определяемых их IE. Потенциальные столкновения при запросах зависят от CID в соответствующих IE.

    Когда SS имеет данные для передачи и хочет войти в процесс разрешения конфликтов, она устанавливает исходное значение ширины окна отсрочки равным отсрочке начала запроса в сообщении UCD. SS случайным образом выбирает число в пределах окна отсрочки. Это случайное число указывает на разрешенное число попыток передачи, которые SS должна пропустить до начала посылки. SS рассматривает только допустимые возможности передачи, которые определяются IE запроса в сообщениях UL-MAP. Каждый IE может содержать много конфликтных возможностей передачи.

    ID канала используется в процессе диспетчеризации для идентификации ресурсных запросов и откликов. Так как такие сообщения являются широковещательными, узлы-получатели могут определить порядок использования как ID узла отправителя в сеточном подзаголовке, так и ID канала в поле MSH-DSCH. Структура ID соединения (CID) описана в таблице 61.

    Таблица 61. Структура CID для сеточного режима

    Синтаксис

    Размер

    Описание

    CID { if(Xmt Link ID == 0xFF)

     

     

    {Logical Network ID}

    8 бит

    0х00: широковещательно

    else {

     

     

    Type

    2 бита

    0х0 MAC управление

    0х1 IP
    0x2-0x3 зарезервировано

    Надежность

    1 бит

     

    Приоритет/Класс

    3 бита

     

    Приоритет отбрасывания}

    2 бита

     

    Xmt Link ID}

    8 бит

    0xFFF: широковещательное управление МАС

    Поле Приоритет/Класс определяет класс сообщения.

    Поле Приоритет отбрасывания определяет вероятность отбрасывания сообщения в случае перегрузки.

    Значение поля Xmt Link ID присваивается узлом отправителем каналу до узла приемника.

    Таблица 62. Кодирование поля Type

    Бит поля Type

    Назначение

    5 (старший)

    Сеточный подзаголовок. 1 = присутствует; 0= отсутствует

    4

    ARQ Feedback Payload (поле данных обратной связи)

    3

    Расширенный тип. 1 = расширенный; 0 = нерасширенный

    Указывает, являются ли расширенными данные подзаголовки упаковки или фрагментации

    2

    Подзаголовок фрагментации. 1=присутствует; 0=отсутствует.

    1

    Подзаголовок упаковки. 1=присутствует; 0=отсутствует.

    0 (младший)

    Подзаголовок управления предоставлением доступа. 1=присутствует; 0=отсутствует. Следует установить равным 0 для DL.

    Может присутствовать четыре типа подзаголовков. Подзаголовки PDU (сеточный, фрагментации и управления предоставлением доступа) могут размещаться в PDU MAC сразу после общего заголовка МАС. Если присутствуют подзаголовки фрагментации и управления предоставления доступа, последний должен быть первым. Если имеется сеточный заголовок, он всегда размещается первым. В таблице 63 представлен формат подзаголовка фрагментации.

    Таблица 63. Структура подзаголовка фрагментации

    Синтаксис

    Размер

    Пояснение

    Подзаголовок фрагментации() {

     

     

    FC

    2 бита

    Индицирует состояние фрагментации поля данных:

    00 = фрагментации нет
    01 = последний фрагмент
    10 = первый фрагмент
    11 = промежуточный фрагмент

    If(Type бит является Extended)

     

    См. табл. 2

    FSN

    11 бит

    Порядковый номер текущего SDU фрагмента. Это поле инкрементируется на 1 (по модулю 2048) для каждого фрагмента, содержащего SDU.

    else

     

     

    FSN

    3 бита

    Порядковый номер текущего SDU фрагмента. Это поле инкрементируется на 1 (по модулю 2048) для каждого фрагмента, содержащего SDU.

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

    3 бита

     

    }

     

     

    Формат подзаголовка упаковки представлен в таблице 64.

    Таблица 64. Формат подзаголовка упаковки

    Синтаксис

    Размер

    Пояснения

    Подзаголовок упаковки() {

     

     

    FC

    2 бита

    Индицирует состояние фрагментации поля данных:

    00 = фрагментации нет
    01 = последний фрагмент
    10 = первый фрагмент
    11 = промежуточный фрагмент

    if(Type бит является Extended)

     

    См.табл. 2

    FSN

    3 бита

    Порядковый номер текущего SDU фрагмента. Это поле инкрементируется на 1 (по модулю 2048) для каждого фрагмента, содержащего SDU.

    else

     

     

    FSN

    3 бита

    Порядковый номер текущего SDU фрагмента. Это поле инкрементируется на 1 (по модулю 2048) для каждого фрагмента, содержащего SDU.

    Длина

    11 бит

     

    }

     

     

    Если бит ARQ обратной cвязи в поле type МАС-заголовка =1, в поле данных транспортируется ARQ-отклик. Если используется упаковка, то он является первым упакованным полем данных.

    Формат сеточного подзаголовка представлен в таблице 65.

    Таблица 65. Формат сеточного подзаголовка

    Синтаксис

    Размер

    Пояснения

    Подзаголовок сетки() {

     

     

    Xmt Node ID

    16 бит

     

    }

     

     

    Таблица 66. Сообщения управления уровня МАС

    Код типа

    Название сообщения

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

    Соединение

    33

    ARQ-Feedback

    ARQ обратная связь для изолированной системы

    Базовое

    34

    ARQ-Discard

    Сообщение отмены ARQ

    Базовое

    35

    ARQ-Reset

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

    Базовое

    36

    REP-REQ

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

    Базовое1

    37

    REP-RSP

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

    Базовое

    39

    MSH-NCFG

    Конфигурации сети

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

    40

    MSH-NENT

    Вход в сеточную сеть

    Базовое

    41

    MSH-DSCH

    Распределенное расписание сетки

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

    42

    MSH-CSCH

    Централизованное расписание для сетки

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

    43

    MSH-CSCF

    Конфигурирование централизованного расписания для сетки

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

    44

    AAS-FBCK-REQ

    Запрос обратной связи AAS

    Базовое

    45

    AAS-FBCK-RSP

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

    Базовое

    38, 46-255

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

     

     

    Во время AAS части кадра сообщения DL-MAP, UL-MAP, DCD, UCD и CLK-CMP должны посылаться с использованием базового CID.

    AAS - Adaptive Antenna System.

    В сеточном (Mesh) режиме узел-кандидат на регистрацию генерирует сообщения REG-RSP, включающие следующие параметры:

    SS MAC-адрес (SS - Subscriber Station)

    Версия MAC (используемая в узле-кандидате)

    HMAC Tuple (дайджест сообщения, вычисленный с помощью HMAC_KEY_U)

    Сообщение REG-REQ может, кроме того, содержать следующие параметры:

    IP-версия

    Возможности кодирования SS

    Идентификатор поставщика кодировщика

    В сеточном режиме при регистрации узел генерирует REG-RSP сообщения, содержащие следующие параметры:

    Node ID (идентификатор узла)

    MAC Version (MAC-версия, используемая в сети)

    HMAC Tuple (дайджест сообщения, вычисленный с помощью HMAC_KEY_D)

    Сообщение REG-RSP может, кроме того, содержать следующие параметры:

    IP-версия

    Возможности кодирования SS. Возможности, указанные в REG-RSP, не устанавливаются выше того, что указано в REG-REQ.

    Специфические расширения поставщика

    Механизм ARQ (Automatic Repeat Request) является опционной частью МАС-уровня и может быть активирован перед формированием соединения. Параметры ARQ согласуются на фазе формирования соединения или изменение его характеристик. В соединении не могут смешиваться трафики поддерживающие и неподдерживающие ARQ. Информация обратной связи ARQ может быть послана в виде управляющего МАС сообщения. Такое сообщение не может быть фрагментировано.

    В таблице определен формат информационного элемента обратной связи ARQ. Элемент используется получателем для сообщения положительного или отрицательного подтверждения. Несколько таких IE может быть помещено в одно поле данных PDU).

    Таблица 67. Формат информационного элемента обратной связи ARQ

    Синтаксис

    Размер

    Комментарий

    ARQ_feedback_IE(LAST) {

     

     

    CID

    16 бит

    Идентификатор сообщения, к которому относится элемент

    LAST

    1 бит

    0= в списке имеются еще IE обратной связи ARQ
    1= последний IE в списке ARQ

    Тип ACK

    2 бита

    0x0 = селективная запись ACK
    0x1 = общая запись ACK
    0x2 = общая запись селективного ACK
    0x3 = зарезервировано

    FSN

    11 бит

     

    Число соответствий (MAP) ACK

    2 бита

    Если тип ACK==01, поле резервируется и устанавливается равным 00. В противном случае в поле записывается число соответствий ACK:

    0x0 =1, 0x1 =2, 0x2 =3, 0x3 =4

    if(ACK тип != 01) {

     

     

    for(i=0; i< NumberOfACK_Maps+1; ++i) {

     

     

    ACK Map

    16 бит

     

    } } }

     

     

    FSN

    if (тип ACK == 0х0): значение FSN соответствует наиболее значимому биту первого 16-битовому коду соответствия ARQ (mapping).

    if (тип ACK == 0х1): значение FSN указывает, что соответствующие его фрагменты с меньшими значениями окна передачи успешно получены.

    if (тип ACK == 0х2): комбинирует ситуации типов 0х0 и 0х1.

    ACK Map

    Каждый бит равный 1 указывает, что на соответствующий фрагмент ARQ получен без ошибки. Бит, соответствующий значению FSN в IE, является наиболее значимым битом в первой записи соответствия. Биты для успешно доставленных номеров фрагментов присваиваются слево-направо в пределах карты соответствия. Если тип ACK равно 0х2, старший бит первой записи соответствия будет установлен равным 1 и IE будет интерпретироваться как совокупный ACK для значения FSN в IE.

    46. Сообщение запроса ключа

    При работе в сеточном режиме используются следующие атрибуты:

    Атрибут

    Содержимое

    Сертификат SS

    Сертификат X.509 узла

    SAID

    Идентификатор SA

    Дайджест HMAC

    HMAC при использовании HMAC_KEY_S

    Формат сообщения обратной связи ARQ

    Синтаксис

    Размер

    Комментарий

    ARQ_Feedback_Message_Format() {

     

     

    Тип сообщения управления = 33

    8 бит

     

    ARQ_Feedback_Payload }

    переменный

     

    47. Сообщение отменыARQ

    Это сообщение применимо только для разрешенных соединений ARQ (табл. 68).

    Таблица 68. Формат сообщения ARQ

    Синтаксис

    Размер

    Комментарий

    ARQ_Discard_Message_Format() {

     

     

    Тип сообщения управления = 34

    8 бит

     

    ID соединения

    16 бит

    CID, к которому относится это сообщение

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

    5 бит

     

    FSN

    11 бит

    Порядковый номер последнего фрагмента в окне передачи, который передающая сторона хочет отменить

    }

     

     

    48. Сообщение сброса ARQ

    Это сообщение может быть послано отправителем или получателем. Сообщение используется в рамках трехэтапного диалога, целью которого является сброс машины состояния ARQ-отправителя или получателя в исходное состояние. Сообщения ARQ-сброса посылаются в виде МАС-сообщений управления.

    Таблица 69. Формат сообщения сброса ARQ

    Синтаксис

    Размер

    Комментарий

    ARQ_Reset_Message_Format() {

     

     

    Тип сообщения управления = 35

    8 бит

     

    ID соединения

    16 бит

    CID, к которому относится это сообщение

    Тип

    2 бита

    00 = Исходное сообщение от инициатора
    01 = Подтверждение от получателя
    10 = Подтверждение от инициатора
    11 = Зарезервировано

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

    6 бит

     

    }

     

     

    49. Формат сообщения (REQ-REQ) запроса результата измерения для канала

    Таблица 70. Формат сообщения REQ-REQ

    Синтаксис

    Размер

    Комментарий

    Report_Request_Message_Format() {

     

     

    Тип сообщения управления = 36

    8 бит

     

    Запрос отчета (TLV)

    перем.

     

    }

     

     

    50. Формат сообщения (REP-REQ) о результате измерения для канала

    Таблица 71. Формат сообщения REP-REQ

    Синтаксис

    Размер

    Комментарий

    Report_Response_Message_Format() {

     

     

    Тип сообщения управления = 37

    8 бит

     

    Отклик-отчет (TLV)

    перем.

     

    }

     

     

    51. Формат сообщения конфигурирования сеточной (MESH) сети (MSH-NCFG)

    Такие сообщения используются для взаимодействия узлов-соседей в сети (BS и SS) для согласования их параметров.

    Таблица 72. Формат сообщения MSH-NCFG

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG _Message_Format() {

     

     

    Тип сообщения управления = 39

    8 бит

     

    NumNmbEntries

    5 бит

     

    NumBSEntries

    2 бита

     

    Флаг вложенного пакета

    1 бит

    0= нет, 1= имеется

    Xmt Power

    4 бита

     

    Xmt Antenna

    3 бита

     

    NetEntry MAC Address Flag

    1 бит

    0= нет, 1= имеется

    Базовый канал сети

    4 бита

     

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

    4 бита

     

    NetConf Count

    4 бита

     

    Временная метка
    Номер кадра
    Номер управляющего сетевого домена в кадре
    Число шагов синхронизации

     
    12 бит
    4 бита
    8 бит

     

    NetConf диспетчерские данные
    Следующий Xmt Mx
    Показатель Xmt Holdoff

     

    3 бита
    5 бит

     

    if(NetEntry MAC Address Flag)
    NetEntry MAC Address

     

    48 бит

     

    for(i=0; i<NumBSEntries; ++i) {

     

     

    Идентификатор узла базовой станции

    16 бит

     

    Число шагов

    3 бита

     

    Xmt energy/bit

    5 бит

     

    }

     

     

    for(i=0; i<NumNmbEntries; ++i)

     

     

    {

     

     

    Nbr Node ID (число идентификаторов)

    16 бит

     

    MSH-Nbr_Physical_IE()

    16 бит

     

    }

     

     

    if(Embedded Packet Flag)
    MSH-Nbr_Logical_IE()

    Переем.

     

    }

     

     

    if(Embedded Packet Flag)
    MSH-NCFG_embedded_data()

    Переем.

     

    }

     

     

    NumNmbEntries

    Число соседей, указанных в сообщении. Число соседей может составлять часть полного набора соседей, известных узлу. Узел может сообщать о дополнительных наборах соседей в последующих сообщениях MSH-NCFG.

    NumBSEntries

    Число соседей сеточной базовой станции (ВS), указанных в этом сообщении.

    Xmt Power

    Мощность передатчика, выраженная через число ступеней, каждая из которых равна 2 dBm, начиная с 8 dBm. То есть 1111 означает 38 dBm.

    Xmt Antenna

    Логическая антенна, используемая для передачи этого сообщения. Это позволяет иметь до 8 антенных направлений.

    Network base channel

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

    Netconf count

    Счетчик пакетов MSH-NCFG, переданных данным узлом. Счетчик используется соседями для детектирования потерянных пакетов. Счетчик увеличивается на 1 после передачи очередного пакета MSH-NCFG.

    Frame Number

    Счетчик по модулю 212, который увеличивается на 1 для каждого кадра.

    Synchronization hop count (число шагов синхронизации)

    Этот счетчик используется для определения относительного приоритета узлов при синхронизации сети. Узлы могут быть времязадающими серверами, синхронизуемыми извне (например, с помощью GPS). Эти узлы транслируют число шагов синхронизации, равное нулю. Узлы синхронизуют другие узлы с более низким числом шагов синхронизации.

    Xmt Holdoff Exponent (показатель)

    Xmt Holdoff Time равно числу возможностей передачи MSH-NCFG по истечении времени Next Xmt.

    Xmt Holdoff Time = 2(Xmt Holdoff Exponent+4) (1)

    Next Xmt Mx

    Next Xmt Time является интервалом пригодности MSH-NCFG для данного соседа. Вычисляется согласно:

    2Xmt Holdoff Exponent ×Next Xmt Mx < NEXT Xmt Time £ 2Xmt Holdoff Exponent ×(Next Xmt Mx+1)

    например, если Next Xmt Mx=3 а Xmt Holdoff Exponent =4, то узел рассматривается рабочим для последующих передач MSH-NCFG между 49 и 64 периодами передачи.

    ID узла BS

    Идентификатор узла сеточной базовой станции.

    Число шагов

    Число шагов между передающим сообщение узлом и узлом сеточной базовой станции.

    Xmt energy/bit factor

    Указывает значение энергии/бит, необходимое для достижения сеточной базовой станции через данный узел. Xmt energy/bit вычисляется по формуле :

    где N набор соседей, оповещающих о сеточной BS, а , PTxравно мощности передачи в мВт из узла i в узел j, а Ri®j- скорость передачи данных в Мбит/с из узла i в узел j. Ej равна Xmt energy/bitуказанному соседом j.

    Указанный Xmt energy/bit factorравен вычисленному значению Xmt energy/bit, поделенному на 2(XmtEnergyUnitExponent-4) .

    XmtEnergyUnitExponent соответствует 4-битовому полю, содержащемуся в дескрипторе сети.

    Nbr node ID

    Идентификатор соседнего узла.

    Формат физического информационного элемента Nbr представлен в таблице ниже.

    Таблица 73. Формат физического информационного элемента

    Синтаксис

    Размер

    Комментарий

    MSH-Nbr_Physical_IE() {

     

     

    Данные о логическом канале имеются

    1 бит

    0= нет, 1= присутствуют

    Логический канал запрошен

    1 бит

    0=Нет, 1= Да

    Логический канал реализован

    1 бит

    0=Нет, 1= Да

    Число шагов до соседа

    1 бит

    0= 1 шаг (непосредственный сосед) 1= 2 шага

    Оценка времени распространения

    4 бита

    в мкс

    Nbr Next Xmt Mx

    5 бит

     

    Nbr Xmt Holdoff Exponent

    3 бита

     

    }

     

     

    Формат логического информационного элемента Nbr представлен в таблице ниже.

    Таблица 74. Формат логического информационного элемента

    Синтаксис

    Размер

    Комментарий

    MSH-Nbr_Logical_IE() {

     

     

    Качество канала Rcv

    3 бита

     

    Профайл импульса Nbr

    4 бита

     

    Запрос дополнительного трафика

    1 бит

    0=Нет, 1= Да

    Мощность Nbr Xmt

    4 бита

     

    Антенна Nbr Xmt

    3 бита

     

    Nbr Xmt Mx

    5 бит

     

    Флаг короткой преамбулы

    1 бит

    0= не используется, 1= использование_запрошено /
    использование_подтверждено

    }

     

     

    Качество канала Rcv

    Мера надежности принимающего канала, указывающая на надежность размера пакетов MSH-NCFG, которые используются указанным профайлом импульса. Надежность вычисляется согласно формуле:

    Надежность=100× (1-10-(Rcv Link Quality+ 1)/4)% (4)

    Профайл импульса Nbr

    Указывает, какой профайл импульса должен использовать узел при посылке порций (импульсов) данных указанному узлу.

    Запрос дополнительного трафика

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

    Мощность Nbr Xmt

    Предлагаемая мощность передачи для данного соседа. Измеряется в единицах, равных 2 дБм, начиная от 8 дБм. (То есть значение 1111 эквивалентно 38 дБм).

    Флаг короткой преамбулы

    Узел может опционно установить этот бит, чтобы использовать короткую преамбулу при передаче информационной части кадра. Возможность передачи короткой преамбулы является обязательной, возможность приема - опционной.

    Данные, содержащиеся в MSH-NCFG имеют формат, представленный в таблице ниже в табл. 75.

    Таблица 75. Формат данных в MSH-NCFG

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG_embedded_data() {

     

     

    Расширенные embedded_data

    1 бит

    0=Нет, 1= Да

    Полученные

    3 бита

     

    Тип

    4 бита

    0=Нет, 1= Да

    Длина

    8 бита

     

    Embedded_data_IE()

    Переем.

    Длина embedded_data в байтах, исключая данный заголовок

    }

     

     

    Тип

    Определены следующие значения поля тип.

    0х0: Полученные
    0х1: Сетевой дескриптор
    0х2: Сетевой вход открыт
    0х3: Сетевой вход закрыт
    0х4: Сетевой вход подтвержден (Embedded_data_IE()==NULL)
    0х5: Протокол установления канала с соседом

    Сетевой дескриптор содержит следующие параметры

    Таблица 76. Параметры сетевого дескриптора

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG _embedded_data() {

     

     

    Код длины кадра

    4 бита

    4 младшие бита протяженности кадра

    MSH-CTRL-LEN

    4 бита

    Длина субкадра управления

    MSH-DSCH-NUM

    4 бита

    Число DSCH-возможностей в субкадре управления

    MSH-CSCH-DATA-FRACTION

    4 бита

     

    Кадры диспетчеризации

    4 бита

    Определяет, сколько кадров имеется в субкадре управления между двумя субкадрами сетевого управления (кратно 4). 0 означает 0 кадров, 1 - 4 кадра и т.д..

    Num_Burst_Profiles

    4 бита

    Число определений профайлов импульса

    ID оператора

    16 бит

     

    }

     

     

    Информационный элемент дескриптора сети имеет формат

    Таблица 77. Формат информационного элемента дескриптора

    Синтаксис

    Размер

    Комментарий

    XmtEnergyUnitsExponent

    4 бита

     

    Каналы

    4 бита

    Число логических каналов

    MinCSForwardingDelay

    7 бит

    Число OFDM символов задержки, введенных между получением и передачей пакетов управления

    ExtendedNeighborhoodType

    1 бит

    0= 2-шаговое соседство

    1= 3-шаговое соседство

    if(Channels)
    MSH-NCFG_Channel_IE()

     

     
    переменное

    for(i=0; i<Num_Burst_Profiles; i++) {

     

     

    Обязательный порог выхода

    8 бит

     

    Обязательный порог входа}

    8 бит

     

    }

     

     

    MSH-CSCH-DATA-FRACTION

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

    ExtendedNeighborhoodType

    Если значение поля =0, тогда анонсируются только узлы с Hops to Neighbor=0; если =1, тогда анонсируются только узлы с Hops to Neighbor=1.

    MinCSForwardingDelay

    Минимальная задержка в OFDM символах, которые будут вводиться между концом приема и началом передачи централизованного сообщения диспетчеризации (то есть MSH-CSCH и MSH-CSCF) любым узлом.

    Формат канального безлицензионного информационного элемента MSH-NCFG представлен ниже в табл. 78.

    Таблица 78. Формат элемента MSH-NCFG

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG_Channel_IE() {

     

    Для безлицензионных каналов

    for(i=0; i<Channels; ++i)

     

     

    Код физического канала

    8 бит

    Физический канал ставится в соответствие логическому каналу i.

    Повторное использование канала

    3 бита

    Минимальное число шагов между каналами, прежде чем канал может быть использован повторно алгоритмом централизованной диспетчеризации. Диапазон равен 1-7 шагов. Равенство 0 запрещает повторное использование

    Флаг пик/среднее

    1 бит

    Регулирующие пределы задаются по пиковым или средним значениям.

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

    2 бита

     

    NumChannelMaps

    2 бита

     

    for(i=0; i< NumChannelMaps; ++i) {

     

     

    Число каналов

    8 бит

    Число узлов, к которым применяются правила

    Max. xmt мощность на входе антенны }

    6 бит

    Регулировочный предел в дБм

    Max. EIRP

    6 бит

    Регулировочный предел в дБм

    }

     

     

    Формат канального лицензионного информационного элемента MSH-NCFG представлен ниже в табл. 79.

    Таблица 79. Формат информационного элемента MSH-NCFG

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG_Channel_IE() {

     

    Для лицензионных каналов

    for(i=0; i<Channels; ++i)

     

     

    Центральная частота физического канала

    24 бита

    Положительное число в кГц

    Полоса физического канала

    8 бит

    Положительное число в 100 кГц

    }

     

     

    Повторное использование канала

    3 бита

    Минимальное число шагов между каналами, прежде чем канал может быть использован повторно алгоритмом централизованной диспетчеризации. Диапазон равен 1-7 шагов. Равенство 0 запрещает повторное использование

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

    5 бит

     

    }

     

     

    Сообщение Network Entry Open (сетевой вход открыт) используется в качестве отклика на запрос MSH-NENT и содержит в себе следующие параметры.

    Таблица 80. Информационный элемент Открытого сетевого входа

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG_embedded_data_IE() {

     

     

    Начало минидомена

    8 бит

    Начало графика для входа верхнего сетевого уровня

    Диапазон минидомена

    8 бит

    Диапазон графика для входа верхнего сетевого уровня

    Номер кадра

    12 бит

    Номер кадра, для которого действует график (расписание)

    Канал

    4 бита

    Логический канал для нового узла для Xmt в оговоренном диапазоне минидомена

    Действенность графика

    12 бит

    Область действия графика в кадрах

    Канал

    4 бита

    Логический канал Rcv для нового узла

    Оцененная задержка распространения

    4 бита

    мкс

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

    4 бита

     

    Отклонение попытки входа в сеть, которое используется для отклонения запросов MSH-NENT содержит следующие параметры.

    Таблица 81. Информационный элемент отказа входа в сеть

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG_embedded_data_IE() {

     

     

    Код режекции

    8 бит

     

    Причина режекции (отклонения)

    160 бит

    Строка ASCII

    }

     

     

    Код режекции

    0x0 Значение оператора аутентификации некорректно
    0x1 Превышение задержки распространения
    0x2 Выбор нового инициатора

    Структура информационного элемента установления канала с соседом показана в табл. 82.

    Таблица 82. Информационный элемент установления соединения с соседом

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG_embedded_data_IE() {

     

     

    Код действия

    2 бита

    0х0 Вызов
    0х1 Отклик на вызов
    0х2 Принято
    0х3 Отклонено

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

    6 бит

     

    if(код действия == 0х0 или 0х1)

     

     

    Значение Nbr аутентификации

    32 бита

     

    if(код действия == 0х1 или 0х2)

     

     

    ID канала

    8 бит

    Идентификатор канала передающего узла для данной связи

    }

     

     

    Значение Nbr аутентификации

    HMAC{Ключ аутентификации | номер кадра | Собственный ID узла, ID другого узла}

    Ключ аутентификации является секретным ключом (полученным от оператора)

    52. Сообщение входа в сеточную сеть (MSH-NENT)

    Сообщения MSH-NENT предоставляют новому узлу средства для синхронизации и первичного входа в сеть Mesh. При посылке сообщения MSH-NENT подзаголовок Mesh устанавливается равным 0х0000 до тех пор, пока узлу не будет присвоен ID. В CID Mesh идентификатор сети установлен равным сетевому коду инициатора или 0х0000, если код неизвестен, а ID канала устанавливается равным 0хАА (широковещательный режим).

    Формат сообщения MSH-NENT показан в табл. 83.

    Таблица 83. Формат сообщения MSH-NENT

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG_message_format() {

     

     

    Тип сообщения управления = 40

    8 бит

     

    Тип

    3 бита

    0х0 Зарезервировано
    0х1 NetEntryAck
    0х2 NetEntryRequest
    0х3 NetEntryClose

    Счетчик Xmt для этого типа

    3 бита

    Для NetEntryAck этот тип подтвержден

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

    2 бита

     

    ID узла инициатора

    16 бит

     

    Мощность Xmt

    4 бита

     

    Антенна Xmt

    3 бита

     

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

    1 бит

     

    if(Тип == 0х2)

     

     

    MSH-NENT_Request_IE()

    перем.

     

    }

     

     


    ID узла инициатора

    МАС-адрес нового узла, пославшего запрос.

    Мощность Xmt

    определяется числом шагов по 2 дБм, начиная с 8 дБм (например, 0хF означает 38дБм)

    Антенна Xmt

    Логическая антенна, используемая для передачи сообщения. Поддерживается до 8 направлений антенны.

    Формат MSH-NENT_request_IE представлен в таблице 84 ниже

    Таблица 84. Формат MSH-NENT_request_IE

    Синтаксис

    Размер

    Комментарий

    MSH-NCFG_request_IE() {

     

     

    MAC-адрес

    48 бит

     

    OpConInfo

    64 бита

     

    Значение оператора аутентификации

    32 бита

     

    Серийный номер узла

    32 бита

     

    }

     

     

    MAC-адрес

    МАС-адрес нового узла, посылающего запрос

    OpConInfo

    Конфигурационная информация оператора (полученная от оператора)

    Значение оператора аутентификации

    HMAC{MAC-адрес | Серийный номер узла | Ключ аутентификации}

    где ключ аутентификации является секретным, полученным от оператора.

    53. Сообщение распределенной сеточной диспетчеризации (MSH-DSCH)

    Сообщения распределенной сеточной диспетчеризации (MSH-DSCH) передаются в сеточном режиме, в случае использования распределенной диспетчеризации. В такой ситуации все узлы периодически передают сообщения MSH-DSCH, чтобы проинформировать всех соседей о графике работы передающей станции. Время передачи определяется тем же алгоритмом что и в случае сообщений MSH-NSFG. Сообщения служат для передачи ресурсных запросов и предоставления их соседям. MSH-DSCH могут применяться и для передачи информации о свободных ресурсах. Эти сообщения не фрагментируются. Формат сообщений MSH-DSCH представлен в таблице 85 ниже.

    Таблица 85. Формат сообщений MSH-DSCH

    Синтаксис

    Размер

    Комментарий

    MSH-DSCH_Message_Format() {

     

     

    Тип сообщения управления = 41

    8 бит

     

    Флаг координации

    1 бит

     

    Флаг запрос/отклик

    1 бит

     

    Счетчик порядкового номера

    6 бит

     

    Число запросов

    4 бита

     

    Число возможностей

    4 бита

     

    Число подтверждений

    6 бит

     

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

    2 бита

     

    if(i=0; i<числа_запросов; ++i)

     

     

    MSH-DSCH_Request_IE()

    16 бит

     

    if(i=0; i<числа_возможностей; ++i)

     

     

    MSH-DSCH_Availability_IE()

    32 бита

     

    if(i=0; i<числа_предоставлений; ++i)

     

     

    MSH-DSCH_Grant_IE()

    40 бит

     

    }

     

     

    Флаг координации

    0 = координировано

    1 = не координировано

    Координированные передачи MSH-DSCH осуществляются с помощью субкадров управления. В обоих случаях для установления режима требуется тройной обмен (запрос, предоставление, подтверждение предоставления). Не координированный обмен возможен только в минидоменах, которые не создают помех координированной диспетчеризации.

    Флаг запрос/отклик

    0 = сообщение запроса

    1 = предоставление (используется и для подтверждения предоставления)

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

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

    Счетчик порядкового номера

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

    Число запросов

    Число запросов IE в сообщении.

    Число возможностей

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

    Число подтверждений

    Число подтверждений (grant) в сообщении.

    54. Информационный элемент диспетчеризации MSH-DSCH

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

    Next Xmt Mх

    Время Next Xmt равно следующему приемлемому интервалу MSH-DSCH для этого узла и вычисляется как:

    2XmtHoldoffExponent × NextXmt Mx<Время NextXmt£ 2XmtHoldoffExponent×(NextXmt Mx+1)

    Например, если NextXmt Mx=3 и Xmt Holdoff Exponent =4, тогда для узла будет рассматриваться возможным отправка следующего сообщения MSH-DSCH между 49 и 64 (с учетом гранулярности) возможностями передачи. Если поле NextXmt Mx содержит код 0х1F (все единицы), тогда соседа следует рассматривать способным передать сообщение с момента, определяемого этой величиной и в любое время, соответствующее возможностям MSH-DSCH после этого.

    Следующий Xmt Mх соседа

    Уведомляет о следующем Xmt Mх, как это было сообщено соседом.

    Xmt Holdoff Exponent

    Xmt Holdoff Time равно числу возможностей передачи MSH-DSCH после Next Xmt Time (существует MSH-CTRL-LEN-1 возможностей на один субкадр сетевого управления)

    Показатель Xmt Holdoff соседа

    Анонсирует показатель Xmt Holdoff, сообщенный соседом.

    Число SchedEntries

    Число диспетчерных вложений MSH-DSCH соседа в сообщении.

    ID узла соседа

    ID узла, сообщенное соседом.

    Информационный элемент диспетчеризации MSH-DSCH

    Таблица 86. Информационный элемент MSH-DSCH

    Синтаксис

    Размер

    Комментарий

    MSH-DSCH_scheduling_IE() {

     

     

    NextXmt Mx

    5 бит

     

    Показатель Xmt Holdoff

    3 бита

     

    Число SchedEntries

    8 бит

     

    for(i=0; i<No_ SchedEntries; ++i) {

     

     

    ID узла соседа

    16 бит

     

    Следующий Xmt Mх соседа

    5 бит

     

    Показатель Xmt Holdoff соседа

    3 бита

     

    } }

     

     

    55. Информационный элемент запроса MSH-DSCH

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

    Таблица 87. Запрос, содержащийся в сообщении MSH-DSCH

    Синтаксис

    Размер

    Комментарий

    MSH-DSCH_Request_IE() {

     

     

    ID канала

    8 бит

     

    Уровень требования

    3 бита

     

    Протяженность (persistence)

    3 бита

     

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

    1 бит

     

    }

     

     

    ID канала

    ID, присвоенное передающим узлом каналу до соседа, который относится к данному запросу.

    Уровень требования

    Требуемое число минидоменов.

    Протяженность

    Поле протяженность для запроса. Число кадров, где присутствует запрос.

    0 = аннулировать резервирование

    1 = одиночный кадр

    2 = 2 кадра

    3 = 4 кадра

    4 = 8 кадров

    5 = 32 кадра

    6 = 128 кадров

    7 = сохраняется вплоть до аннулирования или уменьшения

    56. Информационный элемент возможностей MSH-DSCH

    Возможности, записанные в сообщении MSH-DSCH, будут использоваться для указания на свободные диапазоны минидоменов, которым соседи могут предоставить доступ. В перечень возможностей могут входить:

    Таблица 88. Информационные элементы возможностей MSH-DSCH

    Синтаксис

    Размер

    Комментарий

    MSH-DSCH_Availability_IE() {

     

     

    Начальный номер кадра

    8 бит

    8 младших бит номера кадра

    Начало минидомена

    8 бит

     

    Диапазон минидомена

    7 бит

     

    Направление

    2 бита

     

    Протяженность (persistence)

    3 бита

     

    Канал

    4 бита

     

    }

     

     

    Начальный номер кадра

    Младшие 8 бит номера кадра, где начинается IE Availability

    Диапазон минидомена

    Число свободных минидоменов

    Направление

    0= доступность аннулируется

    1= доступна для передачи в этом диапазоне минидоменов

    2= доступна для приема в этом диапазоне минидоменов

    3= доступна для приема и передачи

    Протяженность

    Поле persistence для возможностей. Число кадров, для которых Availability действительна.

    0= доступность аннулируется

    1 = одиночный кадр

    2 = 2 кадра

    3 = 4 кадра

    4 = 8 кадров

    5 = 32 кадра

    6 = 128 кадров

    7 = сохраняется вплоть до аннулирования или уменьшения

    Канал

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

    57. Информационный элемент предоставления MSH-DSCH

    Элементы предоставления передаются в сообщении MSH-DSCH и несут в себе данные о предоставленном интервале минидоменов из выбранном из диапазона доступных. Элементы предоставления могут использоваться для предоставления минидоменов и для подтверждения такого предоставления. Элемент предоставления (Grants) содержит в себе следующие параметры:

    Таблица 89. Информационные элементы предоставления MSH-DSCH (Grants)

    Синтаксис

    Размер

    Комментарий

    MSH-DSCH_Grants_IE() {

     

     

    ID канала

    8 бит

     

    Начальный номер кадра

    8 бит

    8 младших бит номера кадра

    Начало минидомена

    8 бит

     

    Диапазон минидомена

    8 бит

     

    Направление

    1 бит

     

    Протяженность (persistence)

    3 бита

     

    Канал

    4 бита

     

    }

     

     

    Направление
    0= от источника запроса
    1= к источнику запроса

    58. Сообщение централизованной диспетчеризации сетки (MSH-CSCH)

    Сообщение MSH-СSCH формируется BS сетки (mesh) при использовании централизованной диспетчеризации. BS передает это сообщение широковещательно всем своим соседям и все узлы с числом шагов меньше чем HRпорог должны переадресовать сообщение MSH-СSCH своим соседям, которые имеют большее значение числа шагов. Во всех этих случаях флаг Grant/Request=0. HRпорог является конфигурационной величиной, которая должна быть известна BS сетки.

    Узлы могут использовать сообщения MSH-СSCH для запросов полосы у BS сетки, установив флаг Grant/Request=1. Каждый узел сообщает об индивидуальных требованиях по трафику каждого дочернего узла субдерева BS. Формат сообщения MSH-СSCH показан в табл. Сообщение содержит следующие параметры:

    Порядковый номер конфигурации

    Указывает на конфигурацию, которая будет использоваться при интерпретации пакета. Конфигурация сопряжена с пакетом MSH-СSCH.

    Флаг Grant/Request

    0= Grant (передается по нисходящему каналу)

    1= Request (передается по восходящему каналу)

    Флаг конфигурации

    Указывает, какой тип сообщения управляющего диспетчеризацией (CSCH или CSCF) будет передано следующим базовой станцией сетки.

    Показатель шкалы потока

    Определяет шкалу предоставляемой полосы. Его величина обычно зависит от числа узлов в сети, достижимой скорости передачи, требований трафика и предоставляемых услуг. Для DL он определяет абсолютное значение предоставляемого потока. Для UL используется наинизшее значение показателя для каждого шага.

    NumFlowEntries

    Число последующих 8-битных полей, упорядоченных согласно их появлению в MSH-CSCF.

    UplinkFlow

    Основа предоставленной/запрошенной полосы в бит/с для восходящего трафика узлов дерева диспетчеризации BS.

    DownlinkFlow

    Параметр, используемый для вычисления предоставленной/ запрошенной полосы в бит/c для нисходящего трафика узла в дереве диспетчеризации BS. Поток характеризует трафик, который исходит или завершается в самом узле (транзитный трафик не учитывается). Действительное значение предоставляемой/запрашиваемой полосы вычисляется как:

    BWтрафик в BS = UplinkFlow A2FlowscaleExponent+14 (бит/c)

    BWтрафик из BS = DownlinkFlowA2FlowscaleExponent+14 (бит/c)

    Флаг диспетчеризации кадра

    Если флаг установлен, выделение потоков произойдет через два кадра, а не через один.

    Узел инициатор

    Три параметра (узел инициатора и профайлы) устанавливаются равными нулю, кроме случаев узлов, которые хотят зарезервировать выделение для инициализации МАС. Узел может установить эти величины, если все его дочерние узлы сообщают о равенстве этих параметров нулю. Сеточная BS в ответ осуществит выделение для индекса узла 0х00, который зарезервирован для этих целей.


    Таблица 90. Формат сообщения MSH-CSCH

    Синтаксис

    Размер

    Комментарий

    MSH-СSCH_ Message_IE() {

     

     

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

    8 бит

     

    Порядковый номер конфигурации

    3 бита

    Последний порядковый номер MSH-CSCF

    Флаг Grant/Request

    1 бит

    0= Grant; 1= Request

    Флаг диспетчеризации кадра

    1 бит

     

    Флаг конфигурации

    1 бит

    0= следующим сообщением управления графиком является MSH-CSCH
    1 = следующим сообщением управления графиком является MSH-CSCF

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

    2 бита

     

    NumFlowEntries

    8 бит

     

    for(i=0; i<NumFlowEntries; ++i) {

     

     

    UplinkFlow

    4 бита

     

    if(Grant/Request Flag ==0)
    DownlinkFlow

    4 бита

     

    }

     

     

    Показатель шкалы потока

    4 бита

     

    Заполнитель

    4 бита

     

    if(Grant/Request Flag ==0) {

     

     

    No_link_updates

    4 бита

     

    for(i=0; i< No_link_updates; ++i) {

     

     

    Свой индекс узла

    8 бит

    Индекс в списке MSH-CSCF

    Индекс узла родителя

    8 бит

    Индекс в списке MSH-CSCF

    Профайл восходящего канала

    4 бита

     

    Профайл нисходящего канала }

    4 бита

     

    } else {

     

    Запрос узла инициатора

    Узел инициатор

    8 бит

    индекс дерева узлов

    Профайл DL

    4 бита

     

    Профайл UL

    4 бита

     

    } }

     

     


    59. Сообщение конфигурации централизованной маршрутизации сетки (MSH-CSCF)

    Сообщение MSH-CSCF передаются широковещательно в сеточном режиме при централизованной диспетчеризации. Сетевая BS посылает широковещательно MSH-CSCF всем своим соседям, и все узлы переадресуют сообщение согласно своему индексу, специфицированному в сообщении. BS генерирует MSH-CSCF в формате, описанном в табл. 91.

    Таблица 91. Формат сообщения MSH-CSCF

    Синтаксис

    Размер

    Комментарий

    MSH-СSCH_Message_IE() {

     

     

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

    8 бит

     

    Порядковый номер конфигурации

    4 бита

     

    NumberOfChannels

    4 бита

     

    for(i=0; i< NumberOfChannels; ++i) {

     

     

    Индекс канала }

    1 бит

     

    Заполнитель

    0-4 бита

    Заполнение до границы байта

    NumberOfNodes

    8 бит

     

    for(i=0; i<NumberOfNodes; ++i) {

     

     

    NodeID

    16 бит

     

    NumOfChildren

    бит

     

    for(j=0; j<NumOfChildren; ++j) {

     

     

    Индекс дочернего узла

    8 бит

     

    Профайл восходящего канала

    4 бита

     

    Профайл нисходящего канала

    4 бита

     

    } } }

     

     


    Порядковый номер конфигурации

    При поступлении нового сообщения конфигурации число инкрементируется на 1.

    NumberOfChannels

    Число каналов доступных для централизованной конфигурации.

    Индекс канала

    Логический индекс физического канала, согласно MSH-NCFG:NetworkDescriptor.

    NumberOfNodes

    Число узлов в дереве диспетчеризации

    Каждая запись дерева диспетчеризации содержит в себе следующие параметры:

    NodeID

    Уникальный идентификатор узла

    NumOfChildren

    Число дочерних узлов данного узла. Дочерним узлом является сосед с числом шагов на 1 больше чем соответствующее число для данного узла.

    Индекс дочернего узла

    Индекс NumOfChildren в этой таблице узла

    60. Запрос/отклик обратной связи канала AAS (AAS-FBCK-REQ/RSP)

    Сообщение AAS-FBCK-REQ/RSP используется системой, поддерживающей AAS (Adaptive Antenna System) и работающей в режиме FDD. Оно может быть использовано системой, поддерживающей AAS и работающей в режиме TDD. Это сообщение служит для запроса канальных измерений, которые помогают при настройке направления адаптивной многовибраторной антенны.

    Таблица 92. Формат сообщения AAS-FBCK-REQ

    Синтаксис

    Размер

    Комментарий

    AAS-FBCK-REQ_Message_IE() {

     

     

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

    8 бит

     

    Номер кадра

    24 бита

     

    NumberOfFrames

    7 бит

     

    Тип данных

    1 бит

    0= измерить только преамбулу DL

    1= Измерить только данные DL (для SS)

    NumberOfFrequencies

    16 бит

     

    Счетчик запросов обратной связи

    8 бит

     

    }

     

     

    Номер кадра

    Номер кадра, с которого начать измерения

    NumberOfFrames

    Число кадров, для которых следует провести измерения

    NumberOfFrequencies

    Значения частот, распределенные по каналу BW так, что первая точка измерения совпадает с нижней границей канала, а последняя с верхней.

    NumberOfFrequencies

    Счетчик по модулю 256 числа посланных сообщений AAS-FBCK-REQ

    Сообщение отклика на запрос AAS-FBCK-REQ посылается по истечении периода измерений. Формат отклика представлен в табл. 93.

    Таблица 93. Формат отклика AAS-FBCK-RSP

    Синтаксис

    Размер

    Комментарий

    AAS-FBCK-RSP_Message_IE() {

     

     

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

    8 бит

     

    for(i=0; i< NumberOfFrequencies; ++i) {
     

     

     

    Re(Frequency_value[i])

    16 бит

     

    Im(Frequency_value[i]) }

    16 бит

     

    Номер запроса обратной связи

    8 бит

     

    }

     

     

    Re(Frequency_value[i]) иIm(Frequency_value[i])

    Действительная (Re) и мнимая (Im) части измеренной амплитуды частоты в измерительной точке в формате целого числа со знаком и фиксированным положением запятой ([+/-][4бита].[11бит].

    Литература

    1. ETSI TR101 177 V1.1.1, Broadband Radio Access Networks (BRAN); Requirements and architectures for broadband fixed radio access networks (HIPERACCESS).

    2. ETSI TR101 853 V1.1.1 (2000-10), Rules for Coexistence of P-P and P-MP systems using different access methods in the same frequency band.

    3. ITU-R Recommendation F.746-1, Radio frequency channel arrangements for fixed services in the range 22.0 GHz to 29.5 GHz.

    4. ITU-R Recommendation F.758-2, Considerations in the development of criteria for sharing between the terrestrial fixed service and other services.

    5. ITU-R Recommendation F.1191, Bandwidths and unwanted emissions of digital radio relay systems..

    6. ITU-R Recommendation F.1249-1, Maximum equivalent isotropically radiated power of transmitting stations in the fixed service operating in the frequency band 25.25.27.5 GHz shared with the intersatellite service.

    7. ITU-R Recommendation F.1399, Vocabulary of terms for wireless access.

    8. ITU-R Recommendation P.452, Prediction procedure for the evaluation of microwave interference between stations on the surface of the Earth at frequencies above about 0.7 GHz..

    9. ITU-R Recommendation P.676-4, Attenuation by atmospheric gases.

    10. ITU-R Recommendation P.838, Specific attenuation model for rain for use in prediction methods.

    11. ITU-R Recommendation P.840-3, Attenuation due to clouds and fog.

    12. ITU-R Recommendation P.1410, Propagation data and prediction methods required for the design of terrestrial broadband millimetric radio access systems.

    13. ETSI EN 301021 v1.4.1 (2001/03) Fixed Radio Systems; Point-to-multipoint equipment; Time division Multiple access (TDMA); Point-to-Multipoint digital radio systems bands in the range 3 GHz to 11 GHz.

    14. Title 47, part 15, http://www.fcc.gov/Bureaus/Engineering_Technology/Documents/ cfr, Federal Communications Commission.

    15. Falconer, D. and Ariyavisitakul, S. L., Frequency Domain Equalization for 2.11 GHz Fixed Broadband Wireless systems,. Tutorial, presented during Session #11 of IEEE 802.16 in Ottawa, Canada, Jan. 22, 2001.

    16. Cantoni A., and Godara, L. C., .Fast Algorithm for Time Domain Broad Band Adaptive Array Processing,. IEEE Trans. Aerops. Electr. Syst., AES-18, 682, Sept. 1982.

    17. Alamouti, S. M., A Simple Transmit Diversity Technique for Wireless Communications,. IEEE Journal on Select Areas in Communications, vol. 16, no. 8, pp. 1451.1458, Oct. 1998.

    18. Viterbi, A. J., Wolf, J. K., Zehavi, E., and Padovani, R., .A pragmatic approach to trellis-coded modulation, IEEE Communications Magazine, July 1989, pp. 11.19.

    19. Wolf, J. K., and Zehavi, E., P2 codes: Pragmatic trellis codes utilizing punctured convolutional codes,. IEEE Communications Magazine, February 1995, pp. 94.99.

    20. ERC Report 72: Compatibility Studies Related to the possible Extension Band for HIPERLAN at 5 GHz, http://www.ero.dk/doc98/Official/pdf/REP072.pdf

    21. IEEE 802.11a-1999: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High Speed Physical Layer in the 5 GHz Band, http://standards.ieee.org/reading/ieee/ std/lanman, select 802.11a-1999.pdf

    22. U. K. Dept. of the Environment, Transport and the Regions, Digest of environmental Statistics, 15/3/2001, http://www.environment.detr.gov.uk/des

    23. ERC Report 15:Compatibility Studies Between Radar and WLANs Operating at Frequencies Around 5.5 GHz, http://www.ero.dk/doc98/Official/pdf/REP015.pdf

    24. ERC/DEC/(99)23 ERC Decision on the harmonised frequency bands to be designated for the introduction of HIPERLANS, 29-11-1999, http://www.ero.dk/doc98/official/pdf/DEC9923E.PDF

    25. CEPT/ERC/REC 70-03 Relating to the use of short range devices (SRD), http://www.ero.dk/doc98/official/pdf/REC7003E.PDF

    26. Liberti, J. C. and Rappaport, T. S., .Smart Antenna for Wireless Communications, Prentice-Hall, Englewood Cliffs, NJ, 1999.

    27. Erceg, V., et al., Channel models for fixed wireless access applications, http://www.wirelessman.org/tg3/contrib/802163c-01_29r4.pdf

    28. USA ITU-R WP7C/24, 8A-9B/3 (2000-2003) Analysis of potential interference between spaceborne SARS and U-NII devices around 5.3 GHz, http://www.itu.int/itudoc/itu-r/sg7/docs/wp7c/2000-03/contrib/024e.html

    Назад: 4.1.8.1 Мобильные телекоммуникации
    Оглавление: Телекоммуникационные технологии
    Вперёд: 4.1.8 Сети IEEE 802.11


     


    ХАЙВЕЙ - лучший российский хостинг-провайдер: хостинг, регистрация доменов, услуга Ваша@почта, поддержка 24 часа


    NetPromoter - единственный российский профессиональный комплекс программ и сервисов для раскрутки сайта и интернет-статистики


    STSS - известный поставщик надежных серверных решений различного назначения на платформе Intel (Xeon) и AMD.


    5-55: the ITIL company. Практический опыт и теоретические знания на лучших семинарах по ITIL и процессам ITSM.


    Подписка на новости IT-портала CITForum.ru
    (библиотека, ftp-архив CITKIT.ru)

    Новые поступления в on-line библиотеку:

    28 апреля

  • Выбор первого дистрибутива Linux: Пособие для начинающих
  • Обфускация и защита программных продуктов
  • Анализ и оптимизация циклов с помощью производящих функций
  • Стратегии объектно-реляционного отображения: систематизация и анализ на основе паттернов

    26 апреля

  • Business Intelligence обещает значительный рост в 2005 году
  • Десять основных тенденций 2005 года в области Business Intelligence и Хранилищ данных
  • Управление эффективностью бизнеса и предсказуемость
  • Увеличение эффективности бизнеса: пять ошибок управления, которых следует избегать
  • Потребность в организационных данных: модель комплексного управления эффективностью бизнеса
  • Технология Хранилищ данных для государственных учреждений
  • Оцените, насколько совершенно ваше Хранилище данных

    21 апреля

  • Исполнение моделей при помощи виртуальной машины
  • Параллельные алгоритмы компьютерной алгебры
  • От стандарта до стандарта (о стандартизации оптических разъемов)
  • За штурвалом IP-станции

    Продолжение дискуссии читателей:

  • Линукс и пользователи, или что мне не нравится в Linux
  • Еще один взгляд на альтернативные ОС (и софт для них)
  • О некомпетентности пользователя Windows
  • Переписка Долгачева В.С. и Монахова В.В.

    19 апреля

  • Межпротокольный шлюз NAT-PT с функциями DNS-ALG и FTP-ALG для обеспечения взаимодействия между сетями IPv4 и IPv6
  • Рефакторинг архитектуры программного обеспечения: выделение слоев
  • Комбинаторика слов и построение тестовых последовательностей
  • Функциональное тестирование Web-приложений на основе технологии UniTesK

    14 апреля

  • Как организовать двойную парольную защиту данных в Oracle
  • Деревянный интерфейс

    Продолжение дискуссии читателей:

  • Microsoft против мира
  • Впечатления от прочитанного

    12 апреля

  • Крупные проблемы и текущие задачи исследований в области баз данных
  • Глава 2 из книги Т.Кайта "Oracle для профессионалов"Архитектура

    Дискуссия читателей о Linux и Windows:

  • Деньги правят миром, и у кого их больше, тот и прав!
  • О злокозненности некомпетентных пользователей, или почему я не люблю ограниченных пользователей Windows

    7 апреля

  • О доблести Билла Гейтса, или почему Windows лучше, чем LINUX или Mac OS
  • Витая пара - все ли так просто?!
  • Выбираем сервер печати
  • Один слой хорошо, а два - лучше (о пишущих DVD-приводах)

    5 апреля

  • Использование Caché SQL Gateway
  • Глава 19 из книги Т.Кайта "Oracle для профессионалов"Хранимые процедуры на языке Java
  • Что такое PostgreSQL?
  • Обновлен PostgreSQL FAQ

    31 марта

  • Использование Веб-сервисов в Caché
  • Защита на уровне строк (Oracle)
  • Секции в реальном мире

    29 марта

  • Разработка успешных приложений для Oracle - первая глава из книги Тома Кайта "Oracle для профессионалов"
  • Web-сервисы: растущие опасения (мнение аналитиков IDC)
  • Технология OLAP - мощная альтернатива электронным таблицам
  • Какой модной стала подготовка отчетности

    24 марта

  • Многоверсионность данных и управление параллельными транзакциями
  • Исключение из правил. Опыт разработки и внедрения финансовой корпоративной системы
  • Обнаружение компрометаций ядра Linux с помощью gdb
  • Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции
  • Сервис-ориентированная архитектура
  • Бизнес-процессы и XML

    22 марта

  • Доступно. И точка! (обзор точек беспроводного доступа)
  • Коммутаторы Fast/Gigabit Ethernet для "большой" сети
  • Push to Talk: нажми на кнопку и ...говори
  • Сети нового поколения и технология softswitch

    17 марта

  • Часто задаваемые вопросы о proxy (proxy FAQ)
  • Самонастраивающаяся база данных: управляемые приложения и настройка SQL
  • Еще раз о волоконных трассах
  • Настраиваем русский Unicode в FreeBSD-5.3.

    10 марта

  • Еще не сказанное о волоконной оптике
  • Wi-Fi на службе оператора
  • Пора менять платформу?
    (о сокетах LGA775 и PGA478)

    Oracle:

  • Детальный аудит для практических целей
  • Шифруем свои ресурсы данных

    3 марта

  • Требования к проекту. Классификация - первый шаг к пониманию
  • Gtk vs. Qt: драки не будет
  • Управление бизнесом "по максимуму": BPM для финансовых учреждений
  • Реализация решения по управлению эффективностью бизнеса
  • Новые SerialATA-винчестеры
  • Карман для сервера

    1 марта

  • Выбрать корпус - нет ничего проще?
  • Создание виртуальной сети с удаленной загрузкой узлов
  • Текущее состояние и перспективы развития рынка интеграционных технологий
  • Интеграция корпоративной информации: новое направление
  • Архитектурные подходы к консолидации

    24 февраля

  • Каждому проекту своя методология
  • Императив интеграции
  • Безопасность IP-телефонии - полевые зарисовки
  • О злокозненности Билла Гейтса, или почему я не люблю Windows

    22 февраля

  • Oracle10: шифруем данные
  • В версии Oracle10 "виртуальные частные базы данных" данных стали избирательнее
  • Каждому (пользователю) свое (данное в таблице)
    Часть 1
    Часть 2
  • Ускоряем интернет
  • Сетевая аутентификация на практике
  • В фокусе Microsoft Virtual Server 2005

    17 февраля

    Открыт новый раздел
    Все об Open Source

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы - pr@citforum.ru, тел. +7 095 4119920 Пресс-релизы - manager@citforum.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...