Системы радиосвязи и сети телерадиовещания.-2

	31	TFTP-CPLT	Сообщение завершения	Первичное
			конфигурационного файла TFTP	управление
	32	TFTP-REP	Отклик завершения конфигурационного	Первичное
			файла TFTP	управление
	33-		Зарезервировано на будущее
	255

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

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

							Таблица 9.6. Формат сообщения DCD
	Синтаксис			Размер			Описание
DCD_Message_Format () {
Тип управляющего сообщения = 1				8 бит
Идентификатор нисходящего				8 бит
канала
Число изменений конфигурации				8 бит
Информация о канале в формате				перем.
TLV
Начало секции, специфической для
PHY
for(i=1; i<=n; i++)							Для каждого профиля нисходящего канала
							с 1 до n
Downlink_Burst_Profile}							Зависит от PHY

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

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

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

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

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

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

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

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

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

Тип кода FEC

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

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

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

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

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

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

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

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

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

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

Профайл кластера (burst)	DIUC
Профайл DL 1	0
Профайл DL 2	1
Профайл DL 3	2
Профайл DL 4	3
Профайл DL 5	4
Профайл DL 6	5
Профайл DL 7	6
Профайл DL 8	7
Профайл DL 9	8
Профайл DL 10	9
Профайл DL 11	10
Профайл DL 12	11
Профайл DL 13	12
Зарезервировано	13

Зазор (Gap)	14
Конец таблицы DL-MAP	15

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

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

	Синтаксис			Размер				Описание
	Тип=1		8		бит
	Длина			перем.
	Зарезервировано		4		бита			Следует устанавливать в 0
	DUIC		4		бита
	Информация в формате TLV		перем.

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

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

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

блоки FEC - вариант TDM

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

блоки FEC - вариант TDMA

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

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

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

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

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

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

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

DIUC	Назначение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

							Таблица 9.10. Формат сообщения UCD
	Синтаксис			Размер			Описание
UCD_Message_Format
Тип управляющего сообщения = 0				8 бит
Идентификатор восходящего канала				8 бит
Счетчик изменений конфигурации				8 бит
Размер минидомена (minislot)				8 бит

Начало отсрочки передачи	8 бит
Конец отсрочки передачи	8 бит
Запрос начала отсрочки	8 бит
Запрос конца отсрочки	8 бит
Информация о канале в кодировке	перем.
TLV
Начало секции, специфической для
PHY
for(i=1; i<=n; i++)		Для каждого профиля восходящего канала
		с 1 до n
Uplink_Burst_Profile }	перем.

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

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

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

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

Таблица 9.11. Формат сообщения 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, посланного в период управления инициализацией является фиксированной.

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

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

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

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

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

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

МАС-адрес SS

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

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

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

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

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

Таблица 9.12. Формат сообщения 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 диапазона.

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

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

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

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

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

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

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

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

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

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

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

SS:

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

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

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

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

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

	Синтаксис			Размер			Описание
	REG-RSP_Message_Format
	Тип управляющего сообщения = 7			8 бит
	Отклик			8 бит
	Данные, закодированные в форме TLV			перем.

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

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

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

Отклик

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

0 = ok

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

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

Версия МАС

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

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

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

вREG-REQ или BS требует использования нестандартного значения параметра:

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

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

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

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

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

(PKM-REQ/PKM-RSP)

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

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

	Значение			Имя			Описание сообщения
	типа			сообщения