Cети и системы радиосвязи и средства их информационной защиты
..pdf
250
Существенным отличием стандарта IEEE 802.16 от IEEE 802.11 является возможность использования протокола с разрешением конфликтов. Устройства стандарта IEEE 802.11 работают по принципам Ethernet: все они имеют равные права на доступ к радиотракту, а попытавшись одновременно установить связь, разрешают конфликты, повторяя попытки захвата среды через случайное время. В сетях стандарта IEEE 802.16 имеется выделенное устройство — базовая станция оператора, которая раздает своим подчиненным права доступа к радиосреде. В результате имеется возможность более эффективно использовать радиочастотный ресурс и обеспечить эффективную передачу данных.
Базовые станции (Base Station, BS), как правило, применяют мультиплексирование с разделением по времени (TDM), при котором каждой абонентской станции (Subscriber Station, SS) последовательно выделяются временные слоты. Абоненты же разделяют общий канал посредством схемы множественного доступа с разделением по времени (Time
Division Multiple Access, TDMA).
Для реализации дуплексного режима обмена данными используются две технологии: дуплексный режим с разделением по времени (TDD) нисходящего (DownLink) и восходящего (UpLink) потоков (при этом задействуется общий канал связи) и дуплексный режим с разделением по частотам (FDD), когда нисходящий и восходящий потоки оперируют на разных каналах и обмен данными может выполняться одновременно.
Сообщения управления МАС
Определен набор управляющих сообщений МАС. Эти сообщения транспортируются в блоках данных MAC PDU. Все управляющие сообщения МАС начинаются с поля тип сообщения и могут содержать дополнительные поля. Управляющие сообщения для базовых, широковещательных и исходных соединений (initial ranging) не могут быть фрагментированы или упакованы. Управляющие сообщения первичного соединения могут быть упакованы и/или фрагментированы. Значения поля тип сообщения представлены в табл. 9.5. Управляющие сообщения не могут передаваться через транспортные соединения.
|
|
|
|
|
|
|
|
Таблица 9.5. Значения поля тип |
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Тип |
|
|
Имя сообще- |
|
|
Описание сообщения |
|
|
Соединение |
|
|
|
|
|
|
|
|
|||||
|
|
|
ния |
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
0 |
|
|
UCD |
|
|
Дескриптор восходящего канала |
|
|
Широковещательное |
||
|
|
|
|
|
|
|
|
|
|
||
1 |
|
|
DCD |
|
|
Дескриптор нисходящего канала |
|
|
Широковещательное |
||
|
|
|
|
|
|
|
|
|
|
||
2 |
|
|
DL-MAP |
|
|
Определение доступа к нисходящему каналу |
|
|
Широковещательное |
||
|
|
|
|
|
|
|
|
|
|
||
3 |
|
|
UL-MAP |
|
|
Определение доступа к восходящему каналу |
|
|
Широковещательное |
||
|
|
|
|
|
|
|
|
|
|
||
4 |
|
|
RNG-REQ |
|
|
Запрос диапазона |
|
|
Исходное или базовое |
||
|
|
|
|
|
|
|
|
|
|
||
5 |
|
|
RNG-RSP |
|
|
Отклик диапазона |
|
|
Исходное или базовое |
||
|
|
|
|
|
|
|
|
|
|
||
6 |
|
|
REG-REQ |
|
|
Запрос регистрации |
|
|
Первичное управле- |
||
|
|
|
|
|
|
|
|
|
|
|
|
251
|
|
|
ние |
|
|
|
|
|
|
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 |
Первичное управле- |
|
ние |
||||
|
|
|
||
|
|
|
|
252
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. Каждому интервалу с помощью сообщения DL-MAP ставится в соответствие DIUC.
Каждый Downlink_Burst_Profile в сообщении DCD содержит следующие парамет-
ры:
Тип модуляции
Тип кода FEC
Длина последнего кода
Порог обязательного выхода DIUC
Порог минимальной записи DIUC
Присутствие преамбулы
253
Если тип кода 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 |
бита |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
254
Информация в формате 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
255
Рис. 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.
257
Идентификатор канала, к которому относится сообщение. Идентификатор произвольно выбирается 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, зако-
258
дированных в формате 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
Аномалии рабочего диапазона
259
Сообщение отклика на запрос диапазона (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
Синтаксис |
Размер |
Описание |