Сети IEEE

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

Технология беспроводных сетей WLAN (Wireless LAN) развивается довольно быстро. Эти сети удобны для подвижных средств в первую очередь, но находят применние и в других областях (динамичные сети фирм, больницы и т.д.). Наиболее перспективным представляется проект IEEE 802.11, который должен играть для радиосетей такую же интегрирующую роль как 802.3 для сетей Ethernet и 802.5 для Token Ring. В протоколе 802.11 используется алгоритм доступа и подавления cтолкновений, похожий на 802.3, но здесь вместо соединительного кабеля используются радиоволны (Рис. 4.1.8.1.)

Рис. 4.1.8.1. Схема беспроводной локальной сети

Стандарт 802.11 предполагает работу на частоте 2.4-2.4835 ГГц при использовании 4FSK/2FSK FHSS и DSSS-модуляции (Direct Sequence Spread Spectrum), мощность передатчика 10мВт-1Вт. В данном частотном диапазоне определено 79 каналов с полосой 1 Мбит/с каждый. Максимальная пропускная способность сети составляет 2 Мбит/с (в условии малых шумов). Первая локальная сеть 802.11a использовала метод OFDM (Orthogonal Frequency Division Multiplexing). Существует несколько модификаций стандарта и соответствующих регламентирующих документов (смотри , а также ):

802.11D - Additional Regulatory Domains

802.11E - Quality of Service

802.11F - Inter-Access Point Protocol (IAPP)

802.11G - High data rates at 2.4 GHz

802.11H - Dynamic Channel Selection and Transmission Power Control

802.11i - Authentication and Security

Существуют каналы, работающие в инфракрасном диапазоне длин волн (850 или 950 нм). Здесь возможны две скорости передачи 1 и 2 Мбит/с. При скорости 1 Мбит/c используется схема кодирования с группированием четырех бит в 16-битовое додовое слово, содержащее 15 нулей и одну 1 (код Грея). При передаче со скоростью 2 Мбит/c 2 бита преобразуются в 4-битовый код, содержащий лищь одну 1 (0001, 0010, 0100 и 1000).

DSSS в 802.11 использут DBPSK (Differential Binary Phase Shift Keying) для 1 Мбит/с и DQPSK (Differential Quadrature Phase Shift Keying) для 2 Мбит/с, а высокоскоростное DSSS (DSSS/HR применяемое в IEEE 802.11b) использует схему модуляции ССК (Complementary Code Keying), которая допускает скорости передачи 5,5 и 11 Мбит/с.
В случае DSSS каждый бит передается в виде 11 элементарных сигналов, которые называются последовательностью Баркера. Все эти три вида модуляции могут сосуществовать. В протоколе предусмотрена коррекция ошибок FEC (смотри описание в статье о Bluetooth). IEEE 802.11a специфицирует систему кодирования OFDM скорости передачи 6, 9, 12, 18, 24, 36, 48 и 54 Мбит/с. В последнее время широкое распространение получила модификации IEEE 802.11b (WiFi - Wireless Fidelity), которая может обеспечить скорость 1, 2, 5,5 и 11 Мбит/с (модуляция DSSS). Здесь применен алгоритм доступа к сетевой среде CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). Для стандарта IEEE 802.11b доступно 11-14 радиоканалов в частотном диапазоне 2,4 ГГц. Здесь все зависит от местных регламентаций и ограничений. Возможно использование всенаправленных и узконаправленных антенн (последние для стационарных соединений точка-точка). Всенаправленная антенная система гарантирует связь для расстояний до 45 метров, а узконаправленная - до 45 км. При скорости 1 Мбит/с расстояние надежной связи может достигать нескольких сот метров. Предельно возможная скорость обмена определяется автоматически. Одновременно может обслуживаться до 50 клиентов. Важной особенностью является возможность работы с мобильными клиентаими. Улучшенная версия 802.11b называется 802.11g. Этот стандарт принят в 2001 году, в нем применяется метод модуляции OFDM. Теоретически максимальная скорость передачи составляет 54 Мбит/c.

Следует учитывать, что беспроводные каналы шумны и малонадежны, этому способствуют наводки от СВЧ-печей, работающих практически в том же частотном диапазоне. Если вероятность искажения одного бита равна р, вероятность того, что n-битовый кадр будет принят корректно, равна ~(1-p)n. Для Ethernet кадра максимальной длины при p=10-4 вероятность безошибочной доставки составит менее 30%. При p=10-5 будет искажаться один из 9 кадров. По этой причине при работе с радиоканалами следует ориентироваться на короткие кадры.



Топологически локальная сеть IEEE 802. 11b строится вокруг базовой станции (смотри описание стандарта bluetooth), через которую производится связь с Интернет. Но возможны схемы с несколькими базовыми станциями. В этом случае используется протокол STP (Spanning-Tree Protocol), чтобы исключить возможность формирования циклических структур. Базовые станции могут работать на одних и техже или на разных частотных диапазонах. Для организации совместной работы базовых станций используются сигнальные кадры (beacon), которые служат для целей синхронизации. Некоторые современные ноутбуки имеют встроенный Wi-Fi-адаптер. Родоначальником системы Wi-Fi считается Вик Хэйз. Точки доступа к Wi-Fi устанавливаются в библиотеках, кафе, аэропортах, магазинах и т.д.

В 1992 году страны члены ЕС выделили диапазон частот 1,89-1,9 ГГц для целей построения сетей, базирующихся на применение радиосигналов (стандарт DECT - Digital European Cordless Telecommunications). Этот стандарт был разработан для целей передачи данных и голоса в системах сотовой связи. В США для этих же целей используются широкополосные системы с шумоподобным сигналом (SST - ШПС). Для подобных же целей выделены также частотные диапазоны 18 и 60ГГц (диапазон 2,4 ГГц сильно перегружен и “засорен” шумами). Существуют уже системы базирующиеся на Ethernet и Token Ring. Окончательная версия протокола IEEE 802.11 была утверждена в 1997 году.

При относительно малых расстояниях проблем обычно не возникает и работу беспроводной сети действительно можно аппроксимировать алгоритмом CSMA. Но в случае, когда расстояние между передатчиком и приемником сравнимо с радиусом надежной связи, отличие от традиционных сетей становится значительным. Ведь для радиосетей важна интерференция на входе приемника, а не на выходе передатчика (как в CSMA). Рассмотрим вариант сети, изображенный на рис. 4.1.8.2. Если передачу осуществляет узел А, узел С находится вне его радиуса действия и может решить, что можно начать передачу. Излучение передатчика С может вызвать помехи на входе узла В (проблема скрытой станции).

Рис. 4.1.8.2. Схема взаимодействия узлов в беспроводной сети (MACA)

В случае, когда передачу ведет узел В, узел С может решить, что начало передачи сообщения узлу D не возможно, так как в зоне С детектируется излучение станции В (проблема засвеченной станции). Таким образом, в радиосетях, прежде чем начать передачу данных надо знать, имеется ли радио активность в зоне приемника-адресата. В коротковолновых сетях возможна одновременная передача для нескольких адресатов, если они находятся в разных зонах приема.

Ранние протоколы беспроводных локальных сетей базировались на схеме MACA (Multiple Access with Collision Avoidance), разработанной Ф. Карном в 1990 году. Эта схема является основой стандарта IEEE 802.11. В этой схеме отправитель запрашивает получателя послать короткий кадр, будучи принят соседями, предотвратит их передачу на время последующей передачи сообщения адресату. На рис. 4.1.8.2 узел В посылает кадр RTS (Request To Send) узлу C. Этот кадр имеет всего 30 октетов и содержит поле длины последующего сообщения. Узел C откликается посылкой кадра CTS (Clear To Send), куда копируется код длины последующего обмена из кадра RTS. После этого узел В начинает передачу. Окружающие станции, например D или E, получив CTS, воздерживаются от начала передачи на время, достаточное для передачи сообщения оговоренной длины. Станция A находится в зоне действия станции B, но не станции C и по этой причине не получит кадр CTS. По этой причине станция A может начинать передачу, если хочет и не имеет других причин, препятствующих этому. Несмотря на все предосторожности коллизия может иметь место. Например, станции A и C могут одновременно послать кадры RTS станции B. Эти кадры будут неизбежно потеряны, после псевдослучайной выдержки эти станции могут совершить повторную попытку передачи (как в ETHERNET). Стандарт 802.11 не может использовать алгоритм доступа CSMA/CD, работающий в Ethernet.

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


В усовершенствованной схеме требуется подтверждение получения любого информационного кадра, добавлен также механизм оповещения о перегрузке. Стандарт 802.11 поддерживает два режима работы: DCF (Distributed Coordination Function) и PCF (Point Coordination Function). Первый не имеет средств централизованного управления, второй - предполагает, что базовая станция берет на себя функцию управления локальной субсетью (см. рис. 4.1.8.4). В протоколе 802.11 используется алгоритм доступа CSMA/CA (CSMA with Collision Avoidance). При этом производится прослушивание физического и виртуального каналов. CSMA/CA может работать в двух режимах. В первом - станция перед до начала передачи прослушивает канал. Если канал свободен, она начинает передачу данных. При передаче канал не прослушивается и станция передает кадр полностью. Если канал занят, отправитель ждет его освобождения и только после этого начинает передачу. В случае коллизии станции, участвующие в этом событии, смогут начать передачу через псевдостучайный интервал времени (как в Ethernet). Второй режим CSMA/CA базируется на протоколе MACAW и использует контроль виртуального канала, как это показано на рис. 4.1.8.3. В показанном на рисунке примере станция А намеревается передать данные станции В Станция С находится в зоне доступности стации А и, возможно, станции В. Станция D входит в зону доступности станции В, но пребывает в зне зоны досигаемости станции А.



Рис. 4.1.8.3. Прослушивание виртуального канала в протоколе CSMA/CA

Когда станция А решает, что ей необходимо передать данные станции В, она посылет ей кадр RTS, запрашивая разрешение на передачу. Если В может принимать данные, она пришлет отклик в виде кадра CTS. После приема CTS станция А запускает таймер ACK и начинает пересылку данных. При успешном приеме станция В формирует кадр ACK, который посылается А, свидетельствуя о завершении обмена. Если время таймоута ACK истечет раньше, алгоритм повторяется с самого начала. Станция С также принимает кадр RTS и поэтому знает, что по кканалу будут передаваться данные, и по этой причине следует воздержаться от попыток передачи.


Из данных, содержащихся в RTS станция С знает, сколько времени будет продолжаться передача и пребывает в пассивном состоянии. Индикацией этого состояния является последовательность NAV (Network Allocation Vector) (см. рис. 4.1.8.3). Станция D не слышит RTS, передаваемый А, зато воспринимает CTS, посланный станцией В, и также выдает NAV. Следует учитывать, что сигналы NAV не передаются, а являются kbim внутренними напоминаниями хранить радиомолчание. При фрагментировании каждый фрагмент имеет свою контрольную сумму и его получение подтверждается индивидуально. Посылка фрагмента k+1 невозможна пока не получено подтверждение получения фрагмента k. После получения доступа к каналу отправитель может послать несколько кадров подряд. Если фрагмент доставлен с искажением, он пересылается повторно.

Режимы PCF и DCF могут сосуществовать в пределах одной сотовой ячейки. Это достигается путем точного определения межкадрового интервала. Самый короткий интервал SIFS (Short Interframe Interval) используется для того, чтобы одна из сторон, ведущих диалог посредством кадров управления, могла получить возможность начать передачу первой. Всего регламентировано 4 разных типов межкадровых интервалов (SIFS, PIFS, DIFS и EIFS).

Помимо WLAN в настоящее время разработаны стандарты для беспроводных региональных сетей WMAN (Wireless Metropolitan-Area Networks, напимер WiMAX) и WWAN (Wireless Wide-Area Networks) со скоростями обмена в десятки килобит в сек. В текущий момент насчитывается более полудюжины различных типов беспроводных сетей:

GSM Phase 2+

Скорость обмена 9,6-14,4 кбит/c.

Mobitex

Система (WWAN) разработана Ericsson и Swedish Telecom. Расстояние связи < 30 км. MTU=545 байт, скорость обмена 8 кбит/c. RTT может достигать 10 сек.

DataTAC

Эта система известна также под именем ARDIS. Максимальное расстояние связи равно 20 км. Как и в Mobitex связь между базовой станцией и мобильным узлом DataTAC осуществляется в полудуплексном режиме. MTU=2048 байт, скорость обмена 19,2 кбит/с.


Система базируется не на IP-технике.

CDPD (Cellular Digital Packet Data)

Система разработана IBM и McCaw Cellular Communications в начале 90х. MTU=2048 байт, скорость обмена 19,2 кбит/c, время отклика составляет порядка 4 секунд. Обмен может производиться в режиме full duplex.

GPRS (Genetal Packet Radio Service)

Система разработана ETSI в конце 1997 года и работает совместно с GSM. Система может работать с кодовыми схемами CS1, CS2, CS3 и CS4 при скоростях обмена до 60 кбит/c. Мобильные ЭВМ обычно работают с MTU=1500 байт в режиме full duplex.

EDGE (Enhanced Data for GSM Evolution)

Систему называют также улучшенным GPRS, по основным параметрам совпадает со своим прототипом.



К сожалению беспроводные, особенно мобильные каналы крайне ненадежны. Потери пакетов в таких каналах весьма вероятны. Понижение скорости передачи, как правило, не приводит к понижению вероятности потери. Кроме того, проходы от отправителя к получателю здесь неоднородны и могут включать в себя сегменты с различными методами транспортировки данных (проводные и беспроводные). В таких структурах бывает полезно разбить канал на две последовательные связи (indirect TCP). Преимуществом такой схемы является то, что оба виртуальных канала являются однородными. Таймауты в одном из соединений заставят отправителя замедлить темп передачи, в то время как таймауты во втором - могут ускорить обмен. Да и все остальные параметры связей могут оптимизироваться независимо. Основной недостаток этого приема заключается в нарушении базового принципа организации TCP-соединений на основе сокетов, здесь получение подтверждения отправителем не означает благополучной доставки. В 1995 году была предложена схема, не нарушающая TCP-семантику. В этой схеме вводится специальный агент-наблюдатель, который отслеживает состояние кэшей отправителя и получателя и посылает подтверждения. Этот агент при отсутствии своевременного подтверждения запускает процедуру повторной посылки сегмента, не информируя об этом первичного отправителя.


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

При работе с UDP также возникают некоторые трудности. Хотя известно, что UDP не гарантирует доставки, большинство программ, предполагает, что вероятность потери невелика. Программы используют такие способы преодоления потерь, которые при высокой вероятности потери просто не срабатывают. Многие приложения предполагают наличие достаточного запаса пропускной способности, чего в случае мобильной связи обычно нет.

В последнее время в продажу поступили радио-интерфейсы (IEEE 802.11b) для персональных ЭВМ, которые позволяют создавать небольшие офисные сети. Пригодны они и для подключения к каналам Интернет, но в этом случае следует позаботиться о специальной антенне. Такие интерфейсы работают на несущей частоте 2,4-5,0 ГГц и обеспечивают пропускную способность 11-22Мбит/с при расстояниях 700-5000м. Особую привлекательность такие интерфейсы представляют для мобильных ЭВМ. См. LANline Spezial VII/2002, Nov/Dez s16; . Топология радио-сетей достаточно многообразна. Возможны варианты, когда клиенты сети взаимодействуют друг с другом через базовую станцию (см. статью о BlueTooth, рис. 4.1.8.4). Возможна схема взаимодействия все-со-всеми, когда рабочие станции связываются друг с другом непосредственно через эфир. Роль базовой станции может выполнять радио-переключатель или специализированный маршрутизатор.



Рис. 4.1.8.4. Топология WLAN c базовой станцией.

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



Рис. 4.1.8.5. Формат информационного кадра 802.11.

Двухоктетное поле управления кадра имеет 11 субполей. Субполе версия протокола позволяет двум протоколам работать в пределах одной ячейки. Поле тип задает разновидность кадра (информационный, служебный или управляющий), а субтип (RTS, CTS или ACK).


Биты к DS и от DS указывают на направление транспортировки кадра: к межсотовой системе (например, Ethernet() или от нее. Бит MF указывает на то, что далее следует еще один фрагменти. Бит повтор отмечает повторно посылаемый фрагмент. Бит управление питанием используется базовой станцией для переключения в режим пониженного энергопотребления или для выхода из этого режима. Бит продолжение говорит о том, что у отправителя имеются еще кадры для пересылки. Бит W является указателем использования шифрования в теле кадра согласно алгоритму WEP (Wired Equivalent Protocol). Однобитовое поле O сообщает приемнику, что кадры с этим битом (=1) должны обрабатываться строго по порядку.

Поле длительность задает время передачи кадра и его подтверждение. Это поле может присутствовать в служебных кадрах. Именно с учетом этого поля станции выставляют признаки NAV. Заголовок содержит четыре адреса. Это адрес отправителя и получателя, а также адреса ячейки отправителя и места назначения. Поле номер служит для нумерации фрагментов. Из 16 бит номера 12 идентифицируют кадр, а 4 - фрагмент. Управляющие кадры имеют сходный формат, только там отсутствуют поля базовых станций, так как эти кадры не покидают пределов сотовой ячейки. В служебных кадрах отсутствуют поля данные и номер, ключевым здесь является содержимое поля субтип (RTS, CTS или ACK).

Для обеспечения безопасности (ведь к такой сети достаточно легко подключиться) использутся алгоритм WEP (Wired Equivalent Privacy). Длина ключа 40 или 104 разряда. Предусмотрена возможность шифрования сообщений и аутентификации с использованием двухключевых схем. (смотри ).

Стандарт 802.11 требует, чтобы все совместимые беспроводные ЛВС предоставляли девять типов сервисов. Первые пять относятся к услугам распределения и предоставляются базовой станцией, остальные четыре являются станционными. К первой группе относятся:

Ассоциация. Этот вид сервиса используется мобильными станциями для подключения к базовым станциям (БС). Осуществляется это при вхождении станции в зону действия БС.


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

Диссоциация. По инициативе мобильной или базовой станций может быть осуществлен разрыв ассоциации. Это происходит при выключении станции или уходе из зоны действия БС. Инициатором этой операции может быть и БС.

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

Распределение. Этот вид сервиса служит для маршрутизации кадров, посылаемых базовой станции. Если адрес места назначения является локальным, то кадры передаются непосредственно, в противном случае их надо передать по проводной сети.

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

Остальные четыре вида услуг являются внутренними сервисами сотовой ячейки и предоставляются после осуществления ассоциации. В перчень этих сервисов входят:

Идентификация. Этот сервис служит для определения прав доступа станции к ресурсам сотовой ячейки.

Деидентификация. При уходе из сети станция должна выполнить деидентификацию.

Конфиденциальность. Данный сервис служит для шифрования передаваемых конфиденциальных данных. Применяется алгоритм RC4.

Доставка данных. Пересылка, также как и в Ethernet не является гарантированной. Выявлять и исправлять ошибки должны верхние уровни.

Сети с многокаскадными соединениями

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

Среди традиционных сетей особое положение занимают сети, базирующиеся на большом числе идентичных ключевых элементов. Это сети с многокаскадными связями (MIN – Multistage Interconnection Network). Идеология таких сетей используется при построении коммутаторов ATM. Из таких сетей наиболее известной является Delta Banyan (Batcher-switch). Эта сеть содержит регулярную структуру N*N переключателей с двух направлений на два. Сеть содержит log2N число каскадов, каждый из которых имеет N/2 переключателей. Для управления маршрутизацией сообщений в этой сети необходимо log2N бит информации. Схема 4-каскадной сети Delta-2 приведена на рис. 4.1.10.1.

Рис. 4.1.10.1. Блок-схема 4-х каскадной сети Delta-2

Сети управления и сбора данных в реальном масштабе времени (CAN)

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

Стандарт CAN (Controller Area Network - или , а также ) был разработан в Германии компанией Robert Bosch gmbh для автомобильной промышленности (1970 годы). Сеть CAN ориентирована на последовательные каналы связи, выполненные из скрученных пар проводов (или оптических волокон), стандарт определяет протоколы физического уровня и субуровеней MAC и LLC. Все узлы сети равноправны и подключаются к общему каналу. Уровни сигналов протоколом не нормированы. В CAN использована кодировка типа NRZ (Non Return to Xero). Для распознавания сигнатур начала (SOF) и конца (EOF) кадра используется бит-стафинг. В настоящее время в ЕС разрабатывается новый протокол для сети автомобиля, который бы позволял передачу высококачественного стерео аудио и видео сигналов, обеспечивал работу с мобильными телефонными сетями и Интернет. Предполагается, что пропускная способность протокола составит 45 Мбит/c

Высокая надежность и дешевизна сделала сети CAN привлекательными для промышленности и науки. Сеть предназначена для сбора информации и управления в реальном масштабе времени, но может быть использована и для других целей. Канал can реализует принцип множественного доступа с детектированием столкновений (CSMA/CD - Carrier Sense Multiple Access with Collision Detection, аналогично Ethernet). Сеть может содержать только один сегмент. В соответствии со стандартом ISO 11898 сеть способна работать при обрыве одного из проводов, при закоротке одного из проводов на шину питания или на землю. Скорость работы канала программируется и может достигать 1 Мбит/с. Недиструктивная схема арбитража позволяет сделать доступ к общему каналу существенно более эффективным, чем в случае Ethernet. В настоящее время действуют две версии стандарта с полями арбитража длиной в 11 бит (2.0a) и 29 бит (расширенная версия, 2.0b). Код арбитража одновременно является идентификатором кадра и задается на фазе инициализации сети. При одновременной попытке передачи кадров двумя узлами арбитраж выполняется побитно с использованием схемы проволочного “И”, при этом доминантным состоянием является логический “0”.
Выигравший соревнование узел продолжает передачу, а проигравший ждет момента, когда канал освободится. Код-адрес объекта (узла CAN) задается с помощью переключателей на плате CAN при формировании сети.

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

Рис. 4.1.4.1 Стандартный информационный кадр 1 2.0a CAN

Кадр начинается с доминантного бита начала кадра (логический нуль, SOF - start of frame). Далее следует поле арбитража (идентификатор кадра), содержащее 11 бит (эти разряды носят имена id-28, ..., id-18) и завершающееся битом RTR (remote transmission request) удаленного запроса передачи. В информационном кадре RTR=0, для кадра запроса RTR=1. Семь наиболее значимых бит id-28 - id-22 не должны быть никогда все одновременно равными 1. Первым передается бит id28. Доминантные биты r0 и r1 (=0) зарезервированы для будущего использования (в некоторых спецификациях бит r1 называется IDE и относится для стандартных кадров к полю управления). Поле DLC (Data Length Code; биты поля имеют имена dcl3 - dcl0) несет в себе код длины поля данных в байтах. Поле данных, размещенное вслед за ним, может иметь переменную длину или вообще отсутствовать. CRC - циклическая контрольная сумма. В качестве образующего полинома при вычислении CRC используется x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1. Формально, следующий за контрольной суммой бит-разграничитель (=1) принадлежит полю CRC. Поле отклика (ack) содержит два бита, первый из которых первоначально имеет уровень 1, а узлы получатели меняют его значение на доминантное (логический 0). Бит используется для сообщения о корректности контрольной суммы. Второй бит поля всегда имеет уровень логической 1. Завершающее поле EOF (end of frame) содержит семь единичных бит. За этим полем следует поле-заполнитель (INT) из трех единичных бит, после него может следовать очередной кадр. Формат расширенного информационного кадра сети can показан на рис. 4.1.4.2.





Рис. 4.1.4.2. Расширенный информационный кадр 2.0b CAN

Однобитовое субполе SRR (substitute remote request) включено в поле арбитража (идентификатора кадра) и всегда содержит код 1, что гарантирует преимущество стандартного информационного кадра (2.0a) случае его соревнования с расширенным кадром (2.0b) (при равных 11 битах идентификатора). Субполе IDE (identifier extension) служит для идентификации расширенного формата и для этого типа кадра всегда имеет уровень логической 1. Вслед за IDE следует 18-битовое поле (биты имеют имена id-17, ..., id-0; первым передается бит id-28) расширения идентификатора кадра. Контроллеры 2.0b полностью совместимы с кадрами 2.0a и могут посылать и принимать пакеты обоих типов. Идентификаторы в пределах одной сети должны быть уникальными. Следует иметь в виду, что 18-битное поле расширения идентификатора можно при определенных условиях использовать и для передачи информации. Идентификатор не является адресом места назначения, а определяет назначение передаваемых данных (адресация по содержанию). По этой причине пакет может быть принят отдельным узлом, группой узлов, всеми узлами сети или не воспринят вообще. Предельное число различных идентификаторов для версии 2.0a составляет 2032, а для 2.0b превышает 500 миллионов.

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

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



Протокол can имеет развитую систему диагностики ошибок. В результате вероятность не выявленной ошибки составляет менее 4.7ґ 10-11. При выявлении ошибки кадр отбрасывается и его передача повторяется.

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

Любой модуль can может быть переведен в пассивный режим (“состояние сна”), при котором внутренняя активность прекращается, а драйверы отключаются от канала. Выход из этого режима возможен либо по внутренним причинам, либо вследствие сетевой активности. После “пробуждения” модуль ждет, пока стабилизируется его внутренний тактовый генератор, после чего производится синхронизация его работы с тактами канала (11 тактов). Благодаря синхронизации отдельные узлы не могут начать передачу асинхронно (со сдвигом на часть такта). Протокол предусматривает использование четырех типов кадров:

Информационный.

Удаленный запрос (требование присылки информационного кадра с тем же идентификатором, что и запрос).

Сообщение об ошибке.

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

Информационные кадры и удаленные запросы могут использовать как стандартные, так и расширенные форматы кадров (2.0a и 2.0b).

Кадр удаленного запроса может иметь стандартный и расширенный форматы. В обоих случаях он содержит 6 полей: SOF, поле арбитража, поле управления, CRC, поля ACK и EOF. Для этого типа кадров бит RTR=1, а поле данных отсутствует вне зависимости от того, какой код содержится в субполе длины.

Кадр сообщения об ошибке имеет только два поля - суперпозиция флагов ошибки и разграничитель ошибки. Флаги ошибки бывают активными и пассивными. Активный флаг состоит из шести нулевых бит, а пассивный - из шести единиц. Суперпозиция флагов может содержать от 6 до 12 бит. Разграничитель ошибки состоит из восьми единичных бит.

Кадр перегрузки включает в себя два поля - перпозиция флагов перегрузки и разграничитель перегрузки (8 бит =1).


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

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

Детектирование доминантного бита в начале поля int.

Обнаружение узлом доминантного восьмого бита в поле разграничителя ошибки или разграничителя перегрузки.

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

Поля SOF, идентификатор, управляющее поле, данные и CRC кодируются таким образом, что при появлении пяти идентичных бит подряд, в поток вставляется бит противоположного уровня. Так 0000000 преобразуется в 00000100, а 1111110 в 11111010. Это правило не распространяется на CRC-разделители, поля ACK и EOF, а также на кадры сообщения об ошибке или переполнении. Существует 5 разновидностей ошибок (таблица 3.3.4.1).

Таблица 4.1.4.1 Разновидности ошибок.

Тип ошибки	Описание
bit error	Передающий узел обнаружил, что состояние шины не соответствует тому, что он туда передает
stuff error	Нарушено правило кодирования (вставка бита противоположного значения после 5 идентичных бит, см. абзац выше).
CRC error	Приемник обнаружил ошибку в контрольной сумме.
form error	Обнаружено нарушение формата кадра
acknowledgment error	Выявлен неверный уровень первого бита поля ack.

Любой узел CAN должен регистрировать и по запросу сообщать число ошибок при передаче и приеме.

Номинальное время, выделенное для передачи одного бита, включает в себя четыре временные области: sync_seg, prop_seg, phase_seg1, phase_seg2 (рис.3.4.4.3).





Рис. 4.1.4. 3 Временные зоны периода передачи одного бита

Первая временная область (SYNC_SEG) служит для синхронизации работы различных узлов сети. Область PROP_SEG предназначена для компенсации временных задержек в сети и равна сумме времени распространения сигнала по каналу и задержки во входных компараторах. PHASE_SEG1 и PHASE_SEG2 служат для компенсации фазовых ошибок и могут увеличиваться или уменьшаться после синхронизации. T0 - минимальный квант времени, используемый для формирования временной шкалы в пределах периода передачи одного бита (длительность внутреннего такта может быть значительно короче). Момент стробирования определяет момент времени, когда проверяется состояние канала. Этот момент должен быть синхронным для всех узлов сети. Длительность этих временных областей может задаваться программно. Чем длиннее канал, тем меньшую скорость передачи информации он может обеспечить (см. табл. 3.3.4.2).

Таблица 4.1.4.2 Зависимость пропускной способности канала от его длины

Длина канала в метрах	Пропускная способность сети в Кбит/с
100	500
200	250
500	125
6000	10

В сетях CAN используются 9-, 6- и 5-контактные разъемы. Тип разъема, или какие либо его характеристики стандартом не регламентируются. Разъем определяется протоколом HLP (High Layer Protocol).

Следующий Xmt Mх соседа

Уведомляет о следующем Xmt Mх, как это было сообщено соседом.

Сообщение централизованной диспетчеризации сетки (MSH-CSCH)

Сообщение MSH-СSCH формируется BS сетки (mesh) при использовании централизованной диспетчеризации. BS передает это сообщение широковещательно всем своим соседям и все узлы с числом шагов меньше чем HRпорог должны переадресовать сообщение MSH-СSCH своим соседям, которые имеют большее значение числа шагов. Во всех этих случаях флаг Grant/Request=0. HRпорог является конфигурационной величиной, которая должна быть известна BS сетки.

Узлы могут использовать сообщения MSH-СSCH для запросов полосы у BS сетки, установив флаг Grant/Request=1. Каждый узел сообщает об индивидуальных требованиях по трафику каждого дочернего узла субдерева BS. Формат сообщения MSH-СSCH показан в табл. Сообщение содержит следующие параметры:

Сообщение дескриптора нисходящего канала (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 может решить, что остальные поля не изменились и игнорировать оставшуюся часть сообщения.

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

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

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

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

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

Атрибут	Содержимое
Порядковый номер ключа	Порядковый номер ключа авторизации
(один или более) дескрипторов SA	Каждый составной атрибут SA-дескриптора специфицирует идентификатор ассоциации SAID и дополнительные свойства SA

Сообщение команды 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	Зарезервировано

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

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

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

Синтаксис	Размер	Описание
DBPC-REQ_Message_Format() {
Тип управляющего сообщения = 25	8 бит
Данные, закодированные в форме TLV	перем.
}

Сообщение конфигурации централизованной маршрутизации сетки (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 в этой таблице узла

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

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

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

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

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

Код = 10

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

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

Атрибут	Содержимое
Код ошибки	Код, указывающий причину сообщения о недействительности авторизации
Текстовая строка (опционна)	Отображаемая строка, поясняющая причину недействительности авторизации

Сообщение о получении 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 бит
}

Сообщение отклика авторизации (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

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

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

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

Синтаксис	Размер	Описание
DSC-RSP_() {
Тип управляющего сообщения = 15	8 бит
ID транзакции	16 бит
Код подтверждения	8 бит
Данные, закодированные в форме TLV	перем.
}

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

Сообщение отклика (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 включает в себя:

Сообщение отклика на изменение профайла нисходящего канала (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 бита
}

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

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

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

Синтаксис	Размер	Описание
TFTP-CPLT_Message_Format() {
Тип управляющего сообщения = 32	8 бит
Данные, закодированные в форме TLV	перем.
}

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

МАС 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.

Для улучшения эффективности процесса запрос-предолставление предусмотрен механизм диспетчеризации. Путем задания параметров диспетчеризации и 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.

Синхронизация восходящего канала базируется эталонных временных метках восходящего канала, которые задаются счетчиком, инкрементируемым в 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.

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

Структура субкадра нисходящего канала для TDD показана на рис. 15, то же для FDD - на рис. 16.

Возможность передачи определяется наличием свободного минидомена, который может быть использован 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.

Сообщение отклика на запрос базовых возможностей (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, могут успешно использоваться.

Сообщение отклика на запрос диапазона (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 диапазона.

Сообщение отклика на запрос динамического аннулирования сервиса (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, к которому относится подтверждение.

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

Код = 8

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

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

Атрибут	Содержимое
Порядковый номер ключа	Порядковый номер ключа авторизации
SAID	ID ассоциации безопасности
TEK-параметры	Предшествующее поколение параметров ключа, соответствующих SAID
TEK-параметры	Новое поколение параметров ключа, соответствующих SAID
Дайджест HMAC	Дайджест ключевого сообщения, полученный методом SHA

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

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

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

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

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

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

Синтаксис	Размер	Описание
MCA-RSP_Message_Format() {
Тип управляющего сообщения = 22	8 бит
ID транзакции	16 бит
Данные, закодированные в форме TLV	перем.
}

Сообщение отклика регистрации 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 требует использования нестандартного значения параметра:

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

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

Код =9

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

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

Атрибут	Содержимое
Порядковый номер ключа	Порядковый номер ключа авторизации
SAID	ID ассоциации безопасности
Код ошибки	Код, указывающий причину отклонения запроса ключа
Текстовая строка (опционна)	Отображаемая строка, поясняющая отклонение запроса
Дайджест HMAC	Дайджест ключевого сообщения, полученный методом SHA

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

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

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

Код = 6

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

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

Атрибут	Содержимое
Код ошибки	Код ошибки, указывающий на причину отказа авторизации
Опционная отображаемая строка	Текстовая строка, поясняющая причину отклонения авторизации

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

Это сообщение применимо только для разрешенных соединений ARQ (табл. 68).

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

Синтаксис	Размер	Комментарий
ARQ_Discard_Message_Format() {
Тип сообщения управления = 34	8 бит
ID соединения	16 бит	CID, к которому относится это сообщение
Зарезервировано	5 бит
FSN	11 бит	Порядковый номер последнего фрагмента в окне передачи, который передающая сторона хочет отменить
}

Сообщение подтверждения для динамического добавления сервиса (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.

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

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

Синтаксис	Размер	Описание
DSC-ACK_Message_Format() {
Тип управляющего сообщения = 16	8 бит
ID транзакции	16 бит
Код подтверждения	8 бит
Данные, закодированные в форме TLV	перем.
}

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

Сообщение привязки нисходящего канала (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 бита заполнителя }		До границы байта
} } }

Сообщение привязки восходящего канала(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.

Сообщение распределенной сеточной диспетчеризации (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 бит
}

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

Это сообщение может быть послано отправителем или получателем. Сообщение используется в рамках трехэтапного диалога, целью которого является сброс машины состояния ARQ-отправителя или получателя в исходное состояние. Сообщения ARQ-сброса посылаются в виде МАС-сообщений управления.

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

Синтаксис	Размер	Комментарий
ARQ_Reset_Message_Format() {
Тип сообщения управления = 35	8 бит
ID соединения	16 бит	CID, к которому относится это сообщение
Тип	2 бита	00 = Исходное сообщение от инициатора 01 = Подтверждение от получателя 10 = Подтверждение от инициатора 11 = Зарезервировано
Зарезервировано	6 бит
}

Сообщение сверки часов (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).

Сообщение TEK Invalid

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

Код =11

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

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

Атрибут	Содержимое
Порядковый номер ключа	Порядковый номер ключа авторизации
SAID	ID ассоциации безопасности
Код ошибки	Код, указывающий причину сообщения TEK Invalid
Текстовая строка (опционна)	Отображаемая строка, поясняющая причину сообщения TEK Invalid
Дайджест HMAC	Дайджест сообщения, полученный методом SHA

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

Сообщение входа в сеточную сеть (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-адрес | Серийный номер узла | Ключ аутентификации}

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

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

Код = 4

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

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

Атрибут	Содержимое
SS-сертификат	Содержит сертификат Х.509 SS
Возможности безопасности	Описывает запрашиваемые возможности безопасности SS
SAID	Первичный SAID для SS, равный базовому CID

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

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

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

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

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

Синтаксис	Размер	Описание
SBC-REQ_Message_Format() {
Тип управляющего сообщения = 26	8 бит
Данные, закодированные в форме TLV	перем.
}

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

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

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

Синтаксис	Размер	Описание
RNG-REQ_Message_Format() {
Тип управляющего сообщения = 4	8 бит
Идентификатор нисходящего канала	8 бит
Ожидание до завершения	8 бит
Данные, закодированные в форме TLV	перем.
}

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

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

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

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

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

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

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

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

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

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

Синтаксис	Размер	Описание
DSD-REQ_ Message_Format () {
Тип управляющего сообщения = 17	8 бит
ID транзакции	16 бит
ID сервисного потока	32 бит
Данные, закодированные в форме TLV	перем.
}

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

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

Сообщение запроса динамического добавления сервиса 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 будет содержать:

Сообщение запроса 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).

Сообщение запроса изменения профайла нисходящего канала (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) определены в табл. 14.

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

Код = 7

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

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

Атрибут	Содержимое
Порядковый номер ключа	Порядковый номер ключа авторизации
SAID	ID ассоциации безопасности
Дайджест HMAC	Дайджест ключевого сообщения, полученный методом SHA

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

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

Атрибут	Содержимое
Сертификат SS	Сертификат X.509 узла
SAID	Идентификатор SA
Дайджест HMAC	HMAC при использовании HMAC_KEY_S

Формат сообщения обратной связи ARQ

Синтаксис	Размер	Комментарий
ARQ_Feedback_Message_Format() {
Тип сообщения управления = 33	8 бит
ARQ_Feedback_Payload }	переменный

Сообщение запроса регистрации (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

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

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

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

Синтаксис	Размер	Описание
MCA-REQ_Message_Format() {
Тип управляющего сообщения = 21	8бит
ID транзакции	16 бит
Данные, закодированные в форме TLV	перем.
}

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

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

Присвоение

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

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

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

Синтаксис	Размер	Описание
TFTP-CPLT_Message_Format() {
Тип управляющего сообщения = 31	8бит
Данные, закодированные в форме TLV	перем.
}

Сообщения управления ключами конфиденциальности (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 с не соответствующими запросу значениями идентификатора.

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

Определен набор управляющих сообщений МАС. Эти сообщения транспортируются в блоках данных 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		Зарезервировано на будущее

Специфические расширения поставщика

Механизм 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.

Ссылки

Ping Yuan, Violeta Gambiroza, Edward Knightly,

"The IEEE 802.17 Media Access Protocol for High-Spead Metropolitan-Area Resilient Packet Rings", IEEE Network, May/June 2004

Violeta Gambiroza, Ping Yuan, Laura Balzano, Edward Knightly, Yonghe Liu, Steve Sheafor,

"Design, Analysis, and Implementation of DVSR: A High-Performance Protocol for Packet Rings", IEEE/ACM Transactions on Networking, V. 12, N 1, February 2004.

Г.Г. ЯНОВСКИЙ, А.А. РУИН, "Транспортные сети следующего поколения", Вестник связи №2 2004 (http://www.vestnik-sviazy.ru/archive/02_2004/tra.html)

Назад:

Оглавление:

Вперёд:

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

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

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

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

Ниже предлагается конспективное изложение материалов стандарта по документам проектов 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.

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

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

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

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

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

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

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

Xmt Holdoff Exponent

Xmt Holdoff Time равно числу возможностей передачи MSH-DSCH после Next Xmt Time (существует MSH-CTRL-LEN-1 возможностей на один субкадр сетевого управления)

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

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

Запрос/отклик обратной связи канала 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 бит
}

---

---