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

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

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

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

	Синтаксис			Размер			Описание
	PKM-REQ_Message_Format
	Тип управляющего сообщения = 9			8 бит
	Код			8 бит
	Идентификатор PKM			8 бит
	Атрибуты, закодированные в форме TLV			перем.

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

	Таблица 9.17. Формат сообщения PKM
	Синтаксис			Размер			Описание
	PKM-RSP_Message_Format
	Тип управляющего сообщения = 10			8 бит
	Код			8 бит
	Идентификатор PKM			8 бит
	Атрибуты, закодированные в форме TLV			перем.

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

Код

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

9.18.

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

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

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

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

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

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

Атрибуты

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

							Таблица 9.18. Коды сообщений
	Код			Тип PKM-сообщения			Имя управляющего сообщения МАС
0-2				зарезервировано		-
3				SA Add			PKM-RSP
4				Auth Request			PKM-REQ
5				Auth Reply			PKM-RSP
6				Auth Reject			PKM-RSP
7				Key Request			PKM-REQ
8				Key Reply			PKM-RSP
9				Key Reject			PKM-RSP
10				Auth Invalid			PKM-RSP
11				TEK Invalid			PKM-RSP
12				Authent Info			PKM-REQ
13-255				зарезервировано		-

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

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

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

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

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

Код = 4 Атрибуты перечислены в табл. 9.20.

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

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

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

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

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

Код = 5

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

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

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

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

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

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

Код = 6

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

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

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

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

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

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

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

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

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

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

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

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

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

SS.

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

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

Код =9

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

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

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

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

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

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

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

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

Код = 10

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

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

Сообщение TEK Invalid

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

Код =11

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

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

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

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

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

Код = 12

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

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

Атрибут Содержимое СА-сертификат Сертификат производителя SS

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

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

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

	Синтаксис			Размер			Описание
	CLK-CMP_Message_Format() {
	Тип управляющего сообщения = 28			8 бит
	Счетчик синхротактов n			8 бит
	for(i=1; i<-n; i++) {
	Clock ID(i)			8 бит
	Порядковый номер [i]			8 бит
	Результат сравнения[i] }			8 бит

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

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

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

Результат сверки часов 8-битовый код разности (по модулю 256) между следующими двумя эталонными

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

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

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

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

	Синтаксис			Размер			Описание
	DREG-CMD_Message_Format() {
	Тип управляющего сообщения = 29			8 бит
	Код операции			8 бит
	Параметры, закодированные в форме TLV			перем.

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

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

Код

операции

0х00

0х01

0х02

0х03

0х04-0хFF

Операция

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

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

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

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

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

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

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

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

	Синтаксис			Размер			Описание
	DSX-RVD_Message_Format() {
	Тип управляющего сообщения = 30			8 бит
	ID транзакции			16 бит
	Код подтверждения			8 бит

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

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

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

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

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

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

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

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

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

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

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

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

	Фрагмент			FC			FCN
	Первый фрагмент		10				Инкрементируется по модулю 8
	Промежуточный фрагмент		11				Инкрементируется по модулю 8
	Последний фрагмент		01				Инкрементируется по модулю 8
	Нефрагментировано		00				Инкрементируется по модулю 8

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

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

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

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

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

Базовые виды услуг перечислены в таблице 9.36, это UGS (Unsolicited Grant

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