Сообщение дескриптора нисходящего канала (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.
Рис. 8. Объединение MAC PDU (каждое из полей имеет свой уникальный CID)
МАС SDU может быть разделен между одним или более МАС PDU. Это позволяет более эффективно использовать доступную полосу пропускания с учетом требующегося уровня QoS. Фрагментация может быть реализована по инициативе BS или SS. Это определяется на базе формирования соединения. Значения поля FC описаны в табл. 59.
Таблица 59. Значения поля FC
Фрагмент | FC | FCN |
Первый фрагмент | 10 | Инкрементируется по модулю 8 |
Промежуточный фрагмент | 11 | Инкрементируется по модулю 8 |
Последний фрагмент | 01 | Инкрементируется по модулю 8 |
Нефрагментировано | 00 | Инкрементируется по модулю 8 |
Порядковый номер позволяет SS воссоздать исходное поле данных и зарегистрировать потерю любого промежуточного пакета. При потере SS отбрасывает все МАС PDU до тех пор, пока не будет получен новый первый фрагмент или не будет получен нефрагментированный MAC PDU.
В случае включения режима упаковки, МАС может упаковывать по несколько MAC SDU в один MAC PDU. В режиме упаковки используется атрибут соединения, который говорит о том, используются пакеты постоянной длины или переменной. Схема упаковки для МАС-SDU постоянной длины показана на рис. 9, то же для переменной длины отображено на рис. 10.
Рис. 9. Упаковка MAC SDU постоянной длины
Рис. 10. Упаковка MAC SDU переменной длины
Для улучшения эффективности процесса запрос-предолставление предусмотрен механизм диспетчеризации.
Путем задания параметров диспетчеризации и QoS BS может получить требующуюся пропускную способность и время отклика для восходящего канала.
Базовые виды услуг перечислены в таблице 60, это UGS (Unsolicited Grant Service), сервис запросов реального времени rtPS (Real-Time Polling Service), nrtPS (Non.-REAL-Time Polling Service) и сервис наилучшего возможного BE (Best Effort). Каждый вид сервиса приспособлен для определенного типа потока данных.
Таблица 60. Сервисы диспетчеризации и правила использования
Тип диспетчеризации | Комбинированный запрос | Изъятие полосы | Опрос (polling) |
UGS | Не разрешен | Не разрешено | Для запроса уникастного опроса требуемой полосы для соединения не UGS используется бит PM |
rtPS | Разрешен | Разрешено для GPSS | Диспетчеризация допускает только уникастный опрос |
nrtPS | Разрешен | Разрешено для GPSS | Диспетчеризация может ограничить сервисный поток только уникстным опросом через политику передачи/ запросов; в противном случае разрешены все формы опроса |
BE | Разрешен | Разрешено для GPSS | Разрешены все формы опроса |
Когда SS нужно запросить полосу для конкретного соединения с ВЕ диспетчеризацией, она посылает сообщение BS, содержащее требование немедленного соединения DAMA (Demand Assigned Multiple Access). QoS соединения определяется в процессе формирования и обеспечивается BS.
Для получения нужной полосы восходящего канала SS использует запросы, направляемые ею к BS.Так как профайл восходящего канала может меняться динамически, все запросы полосы должны выражаться в байтах, которые необходимы для передачи МАС-заголовка и поля данных, но не должны учитывать издержки физического уровня.
Такие запросы могут быть посланы в период запроса IE или любого кластера предоставления данных типа IE.
В зависимости от характера запроса полосы существует два режима работы SS: GPC (Grant per Connection) и GPSS (Grant per Subscriber Station). В первом случае BS предоставляет полосу конкретно каждому соединению, в то время как во втором случае полоса предоставляется всем соединениям SS. В последнем случае (GPSS) можно использовать меньшую суммарную полосу пропускания, а продвинутая SS может перераспределять полученную от BS полосу. Такой алгоритм удобен для решения задач реального времени, когда требуется более быстрый отклик.
Опрос (polling) является процессом, с помощью которого базовая станция резервирует SS полосу. Это резервирование может быть для отдельной SS или группы станций. Резервирование для группы соединений и/или SS в действительности определяет информационный элемент (IE) соединения при запросе полосы. Заметим, что опрос осуществляется для соединений или для SS. Полоса всегда запрашивается на основе CID, а резервирование полосы осуществляется для соединения (режим GPC) или для SS (режим GPSS).
Когда SS опрашиваются индивидуально, никакого сообщения не посылается, просто производится резервирование для SS в восходящем канале, достаточное для реагирования на запросы полосы. Если SS не нуждается в полосе, она возвращает байт 0xFF. Станции SS, работающие в режиме GPSS, при наличии активного UGS-соединения с достаточной полосой, индивидуально опрашиваться не будет, если только они не выставили бит PM (Poll Me) в заголовке пакета UGS-соединения. Это экономит полосу на опросе всех SS.
Если имеется недостаточная полоса пропускания для индивидуального опроса неактивных SS, некоторые SS могут опрашиваться в составе мультикаст-групп или с привлечением широковещательного опроса Определенные CID зарезервированы для мультикаст-групп и для широковещательных сообщений.
МАС-протокол поддерживает несколько дуплексных технологий. Выбор дуплексной техники может повлиять на определенные параметры уровня PHY, а также на перечень поддерживаемых возможностей.
На МАС-уровне поддерживаются кадровые и бескадровые спецификации PHY. Для бескадрового режима PHY интервала диспетчеризации выбираются МАС. При бескадровой FDD PHY восходящий и нисходящий каналы размещаются на разных частотах, так что каждая SS может осуществлять прием и передачу одновременно. Оба эти канала не используют фиксированной длины кадров. В такой системе нисходящий канал находится всегда во включенном состоянии, и все SS слушают его. Трафик передается широковещательно, используя мультиплексирование по времени (TDM). В восходящем канале применяется режим мультиплексирования TDMA (Time Division Multiple Access).
В кадровой (кластерной) системе FDD (Frequency Division Duplex) восходящий и нисходящий каналы размещаются на разных частотах, а нисходящие данные передаются в виде кластеров (bursts). Для обоих направлений обмена используются кадры фиксированной длины. Это помогает использовать разные типы модуляции. При этом могут применяться полнодуплексные и полудуплексные SS.
В режиме TDD (Time Division Duplexing) восходящий и нисходящий каналы используют одну и ту же частоту. TDD-кадр имеет фиксированную длительность и содержат субкадры для восходящего и нисходящего каналов. Кадр делится на целое число физических доменов (PS-slots), которые помогают легко поделить полосу. Работа системы в режиме TDD и структура TDD-кадра показана на рис. 11.
Рис. 11 Структура TDD кадра
Синхронизация восходящего канала базируется эталонных временных метках восходящего канала, которые задаются счетчиком, инкрементируемым в 16 раз чаще, чем частота PS. Это позволяет часам SS быть хорошо синхронизованными с BS.
В случае бескадрового PHY сообщение привязки (DL-MAP) транслирует широковещательно временную метку всем SS. Эта метка BS используется для подстройки часов всех станций клиентов. После того как временная метка BS или SS достигает максимального значения 229-1, она принимает значение нуль и продолжает инкрементироваться.
Карта резервирования полосы восходящего канала использует в качестве модулей минидомены (minislot).
Размер минидомена определяется как число физических доменов PHY PS и содержится в дескрипторе восходящего канала. Один минидомен содержит n PS, где n целое число из интервала 0-255.
Информация в DL-MAP относится к текущему кадру, то есть к кадру, в котором она доставлена. Информация, доставляемая в UL-MAC, относится к временному интервалу, начинающемуся в момент резервирования (измеряется от начала поученного кадра и до конца последнего зарезервированного минидомена). Пустые IE указывают на паузы в передаче по восходящему каналу. Станции SS не могут осуществлять передачу в это время. Данный вид синхронизации используется как для TDD, так и для FDD. Вариант TDD показан на рис. 12, а вариант FDD на рис. 13.
Рис. 12. Максимальное время релевантности управляющей информации PHY и MAC (TDD)
Рис. 13. Максимальное время релевантности управляющей информации PHY и MAC (FDD)
В бескадровых системах PHY DL-MAP содержит только временные метки восходящего канала и не определяет, какую информацию следует передавать. Все SS постоянно ищут нисходящий сигнал для любого сообщения, которое к ним адресовано. Сообщение UL-MAP содержит временную метку, которая указывает на первый минидомен, который определяет мэпинг. Задержка от конца UL-MAP до начала первого интервала в восходящем канале определенная таблицей соответствия, будет больше максимума RTT плюс время обработки, необходимое SS (см. рис. 14).
Рис. 14. Временная релевантность UL-MAP информации (бескадровое FDD)
Структура субкадра нисходящего канала для TDD показана на рис. 15, то же для FDD - на рис. 16.
Рис. 15. Структура субкадра нисходящего канала для TDD
Рис. 16. Структура субкадра нисходящего канала для FDD
Возможность передачи определяется наличием свободного минидомена, который может быть использован SS для передачи сообщений или данных. Число возможностей передачи связано с конкретным информационным элементом (IE), размером интервала и объемом передачи.
BS контролирует восходящий канал с помощью сообщений UL-MAP и определяет, какие из минидоменов являются объектами столкновений.
Столкновения могут произойти в периоды установления соединения и при запросах, определяемых их IE. Потенциальные столкновения при запросах зависят от CID в соответствующих IE.
Когда SS имеет данные для передачи и хочет войти в процесс разрешения конфликтов, она устанавливает исходное значение ширины окна отсрочки равным отсрочке начала запроса в сообщении UCD. SS случайным образом выбирает число в пределах окна отсрочки. Это случайное число указывает на разрешенное число попыток передачи, которые SS должна пропустить до начала посылки. SS рассматривает только допустимые возможности передачи, которые определяются IE запроса в сообщениях UL-MAP. Каждый IE может содержать много конфликтных возможностей передачи.
ID канала используется в процессе диспетчеризации для идентификации ресурсных запросов и откликов. Так как такие сообщения являются широковещательными, узлы-получатели могут определить порядок использования как ID узла отправителя в сеточном подзаголовке, так и ID канала в поле MSH-DSCH. Структура ID соединения (CID) описана в таблице 61.
Таблица 61. Структура CID для сеточного режима
Синтаксис | Размер | Описание |
CID { if(Xmt Link ID == 0xFF) | ||
{Logical Network ID} | 8 бит | 0х00: широковещательно |
else { | ||
Type | 2 бита | 0х0 MAC управление 0х1 IP 0x2-0x3 зарезервировано |
Надежность | 1 бит | |
Приоритет/Класс | 3 бита | |
Приоритет отбрасывания} | 2 бита | |
Xmt Link ID} | 8 бит | 0xFFF: широковещательное управление МАС |
Поле Приоритет отбрасывания определяет вероятность отбрасывания сообщения в случае перегрузки.
Значение поля Xmt Link ID присваивается узлом отправителем каналу до узла приемника.
Таблица 62. Кодирование поля Type
Бит поля Type | Назначение |
5 (старший) | Сеточный подзаголовок. 1 = присутствует; 0= отсутствует |
4 | ARQ Feedback Payload (поле данных обратной связи) |
3 | Расширенный тип. 1 = расширенный; 0 = нерасширенный Указывает, являются ли расширенными данные подзаголовки упаковки или фрагментации |
2 | Подзаголовок фрагментации. 1=присутствует; 0=отсутствует. |
1 | Подзаголовок упаковки. 1=присутствует; 0=отсутствует. |
0 (младший) | Подзаголовок управления предоставлением доступа. 1=присутствует; 0=отсутствует. Следует установить равным 0 для DL. |
Может присутствовать четыре типа подзаголовков. Подзаголовки PDU (сеточный, фрагментации и управления предоставлением доступа) могут размещаться в PDU MAC сразу после общего заголовка МАС. Если присутствуют подзаголовки фрагментации и управления предоставления доступа, последний должен быть первым. Если имеется сеточный заголовок, он всегда размещается первым. В таблице 63 представлен формат подзаголовка фрагментации.
Таблица 63. Структура подзаголовка фрагментации
Синтаксис | Размер | Пояснение |
Подзаголовок фрагментации() { | ||
FC | 2 бита | Индицирует состояние фрагментации поля данных: 00 = фрагментации нет 01 = последний фрагмент 10 = первый фрагмент 11 = промежуточный фрагмент |
If(Type бит является Extended) | См. табл. 2 | |
FSN | 11 бит | Порядковый номер текущего SDU фрагмента. Это поле инкрементируется на 1 (по модулю 2048) для каждого фрагмента, содержащего SDU. |
else | ||
FSN | 3 бита | Порядковый номер текущего SDU фрагмента. Это поле инкрементируется на 1 (по модулю 2048) для каждого фрагмента, содержащего SDU. |
Зарезервировано | 3 бита | |
} |
Таблица 64. Формат подзаголовка упаковки
Синтаксис | Размер | Пояснения |
Подзаголовок упаковки() { | ||
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.
Сообщение отклика на запрос базовых возможностей (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.
Возможности 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 бит | |
} |