Примеры сетевых топологий
Сообщение отклика на уведомление о завершении копирования конфигурационного файла (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 нужно запросить полосу для конкретного соединения с ВЕ диспетчеризацией, она посылает сообщение 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. Формат подзаголовка упаковки
| Синтаксис | Размер | Пояснения |
| Подзаголовок упаковки() { | ||
| FC | 2 бита | Индицирует состояние фрагментации поля данных: 00 = фрагментации нет 01 = последний фрагмент 10 = первый фрагмент 11 = промежуточный фрагмент |
| if(Type бит является Extended) | См.табл. 2 | |
| FSN | 3 бита | Порядковый номер текущего SDU фрагмента. Это поле инкрементируется на 1 (по модулю 2048) для каждого фрагмента, содержащего SDU. |
| else | ||
| FSN | 3 бита | Порядковый номер текущего SDU фрагмента. Это поле инкрементируется на 1 (по модулю 2048) для каждого фрагмента, содержащего SDU. |
| Длина | 11 бит | |
| } |
Формат сеточного подзаголовка представлен в таблице 65.
Таблица 65. Формат сеточного подзаголовка
| Синтаксис | Размер | Пояснения |
| Подзаголовок сетки() { | ||
| Xmt Node ID | 16 бит | |
| } |
| Код типа | Название сообщения | Описание сообщения | Соединение |
| 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 - 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.
