Документ: 6282, страницы 266-270 | База учебных материалов

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

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
Текстовая строка		Отображаемая строка, поясняющая причину сообщения 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
Фрагмент		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). Каждый вид сервиса приспособлен для определенного типа потока данных.

Материал: 6282

Смотрите также: