Cети и системы радиосвязи и средства их информационной защиты
..pdf260
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) кода аутентификации хэшированного сообщения
261
Следующие параметры включаются в сообщение 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 |
||
|
|
|
|
|
|
|
|
|
|
|
Значение типа |
|
|
Имя сообщения |
|
|
Описание сообщения |
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|||
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 бит |
|
|
|||
|
|
|
|
|
|
|
|
|
|
262
Код |
8 бит |
|
|
|
|
Идентификатор PKM |
8 бит |
|
|
|
|
Атрибуты, закодированные в форме TLV |
перем. |
|
|
|
|
Параметрами этих сообщений являются:
Код
Код содержит один октет и идентифицирует тип РКМ-пакета. Когда пакет приходит с неверным кодом, он молча отбрасывается. Значения кода определены в табл 9.18.
Идентификатор 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 с не соответствующими запросу значениями идентификатора.
Атрибуты
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 |
|
|||
|
|
|
|
|
|
|
|
|
|
263
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 , сообщенный
264
BS в соответствующем Auth Request. Этот список может содержать также дескрипторы статических SAID, к которым разрешен доступ SS.
Код = 5
Атрибуты сообщения Auth Reply представлены в табл. 9.21.
|
|
|
|
Таблица 9.21. Атрибуты сообщения Auth Reply |
|
|
|
|
|
|
|
|
Атрибут |
|
|
Содержимое |
|
|
|
|
|
||
|
|
|
|
|
|
Auth-Key |
|
|
Ключ авторизации, зашифрованный общедоступным ключом клиента SS |
||
|
|
|
|
||
Время жизни ключа |
|
|
Время активной жизни ключа |
||
|
|
|
|
||
Порядковый номер ключа |
|
|
Порядковый номер ключа авторизации |
||
|
|
||||
Один или более дескрипто- |
Каждый составной атрибут дескриптора SA специфицирует SAID и дополни- |
||||
ров SA |
|
|
тельные свойства 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 аутентифицировать сообщения запроса ключа.
Сообщение отклика на запрос ключа
265
Код = 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:
266
по своей инициативе
как отклик на сообщение, полученное от 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
267
Сообщение сверки часов (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. Коды операций
269
Сообщение 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.