Bluetooth® Special Interest Group (SIG) [1] и [2] задает различные пакетные структуры для Bluetooth низкой энергии (BLE) и устройств базовой скорости / улучшенной скорости передачи данных (BR/EDR) Bluetooth.
При определении пакетов и сообщений в основополосной спецификации, порядок битов следует за форматом с прямым порядком байтов. В этом формате применяются эти правила:
Младший значащий бит (LSB) соответствует b 0.
LSB является первым битом, отправленным по воздуху.
При иллюстрировании пакетной структуры LSB показывают на левой стороне.
Кроме того, поля данных, сгенерированные внутренне на основополосном уровне (пакетный заголовок и длина заголовка полезной нагрузки), должны быть переданы с LSB сначала. Например, 3-битный параметр отправляется как: b0b1b2 = 110 по воздуху, куда 1 отправляется сначала и 0, отправляется в последний раз.
Устройства BLE используют форматы пакета в: BLE Незакодированный Физический уровень (PHY), BLE Закодированный PHY, Рекламируя Физический PDU Канала, Данные Физический PDU Канала и Постоянный Тон Дополнительная и Синфазная Квадратура (IQ) Выборка.
Для получения дополнительной информации о пакетной структуре BLE, смотрите объем 6, Часть B, Раздел 2 из Спецификации [2] Ядра Bluetooth.
Спецификация [2] Ядра Bluetooth задает два физических уровня (PHY) режимы передачи (LE 1M и LE 2M) для незакодированного PHY. Этот рисунок показывает пакетную структуру для BLE незакодированный PHY, работающий с LE 1M и LE 2M.
Каждый пакет содержит четыре обязательных поля (преамбула, указатель, модуль данных о протоколе (PDU) и контроль циклическим избыточным кодом (CRC)) и одно дополнительное поле (постоянное тональное расширение (CTE)). Преамбула передается сначала, сопровождается указателем, PDU, CRC и CTE (если есть) в том порядке. Целый пакет передается на том же уровне символа 1 Msym/s или 2 Msym/s.
Преамбула. Все пакеты слоя ссылки (LL) содержат преамбулу, которая используется в получателе, чтобы выполнить синхронизацию частоты, обучение автоматическому управлению усилением (AGC) и оценку синхронизации символа. Преамбула является фиксированной последовательностью чередования 0 и 1 бит. Для пакетов BLE, переданных на LE 1M PHY и LE 2M PHY, размер преамбулы является 1 октетом и 2 октетами, соответственно.
Указатель. Указатель является значением с 4 октетами. Каждая связь LL между любыми двумя устройствами и каждая периодическая реклама обучаются, имеет отличный указатель. Каждый раз, когда устройству BLE нужен новый указатель, LL генерирует новое случайное значение, придерживающееся этих требований:
Значение не должно быть указателем ни для какой существующей связи LL на этом устройстве.
Значение не должно быть указателем ни для какой активированной периодической рекламы, обучаются.
Значение должно иметь не больше, чем шесть последовательных 1 с или 0s.
Значение не должно быть указателем ни для каких рекламных пакетов канала.
Значение не должно быть последовательностью, которая отличается от указателя рекламы физических пакетов канала только на 1 бит.
Все четыре октета для значения не должны быть равными.
Значение должно иметь минимум двух переходов в старших значащих 6 битах.
Если случайное значение не удовлетворяет указанным выше требованиям, новое случайное значение сгенерировано, пока это не удовлетворяет все требования.
PDU. Когда пакет BLE передается или на первичном или на вторичном рекламном физическом канале или периодическом физическом канале, PDU задан как Рекламный Физический PDU Канала. Когда пакет передается на данных физический канал, PDU задан как Данные Физический PDU Канала.
CRC. Размер CRC является 3 октетами и вычисляется на PDU всех пакетов LL. Если PDU зашифрован, то CRC вычисляется после того, как шифрование PDU завершено. Полином CRC имеет форму x 24+x10+x9+x6+x4+x3+x+1.
Для получения дополнительной информации о генерации CRC, смотрите объем 6, Часть B, Раздел 3.1.1 из Спецификации [2] Ядра Bluetooth.
CTE. CTE состоит из постоянно модулируемой серии непобеленных 1 с. Это поле имеет переменную длину, которая лежит в диапазоне от 16 мкс до 160 мкс.
Для получения дополнительной информации о CTE, смотрите объем 6, Часть B, Раздел 2.5.1 из Спецификации [2] Ядра Bluetooth.
Для получения дополнительной информации о BLE незакодированная пакетная структура PHY, обратитесь к Vol 6, Части B, Разделу 2.1 из Спецификации [2] Ядра Bluetooth.
Этот рисунок показывает, что пакетная структура для BLE закодировала PHY и реализована для пакетов BLE на всех физических каналах.
Каждый пакет BLE состоит из преамбулы и этих двух блоков прямого исправления ошибок (FEC):
Блок 1 FEC — Этот блок содержит три поля: указатель, кодирование индикатора (CI) и TERM1. Этот блок реализует S =8 схем кодирования, где каждый бит представляет восемь символов. Это дает скорость передачи данных 125 Кбит/с.
Блок 2 FEC — Этот блок содержит эти три поля: PDU, CRC и TERM2. Этот блок реализует S =8 или S =2 схемы кодирования. В S =2 схемы кодирования каждый бит представляет два символа. Поэтому скорость передачи данных составляет 500 Кбит/с.
Закодированный PHY BLE не содержит CTE.
Преамбула. BLE закодировал преамбулу PHY, 80 символов в длине и содержат 10 повторений шаблона символа '00111100' (в порядке передачи).
Указатель. Длина закодированного указателя BLE PHY является 256 символами. Для получения дополнительной информации смотрите Указатель. В дополнение к требованиям, перечисленным в подразделе указателя раздела BLE Uncoded Physical Layer (PHY), новое значение для указателя закодированного PHY BLE должно также удовлетворить эти требования:
Значение должно иметь по крайней мере три 1 с в последних значимых битах.
Значение должно иметь не больше, чем 11 переходов в младших значащих 16 битах.
CI. Поле CI состоит из двух битов как показано в этой таблице:
| Биты в CI | Описание |
|---|---|
00b | Блок 2 FEC, закодированный с помощью S =8 |
01b | Блок 2 FEC, закодированный с помощью S =2 |
| Все другие значения | Зарезервированный для будущего использования |
PDU. PDU в закодированной пакетной структуре BLE PHY имеет то же форматирование как PDU в BLE незакодированный пакет PHY.
CRC. CRC в закодированной пакетной структуре BLE PHY имеет то же форматирование как CRC в BLE незакодированный пакет PHY.
TERM1 и TERM2. Каждый блок FEC содержит терминатор строки в конце блока. Тот терминатор строки упоминается как TERM1 и TERM2. Каждый терминатор строки 3 бита длиной и формирует последовательность завершения во время процесса кодирования FEC.
Для получения дополнительной информации о закодированной пакетной структуре BLE PHY, смотрите объем 6, Часть B, Раздел 2.2 из Спецификации [2] Ядра Bluetooth.
Пакетный формат структуры рекламного физического PDU канала показывают в этом рисунке.
Рекламный физический PDU канала имеет 16-битный заголовок и полезную нагрузку переменного размера. 16-битное поле заголовка рекламного физического PDU канала показывают в этом рисунке.
Поле типа PDU в рекламном заголовке PDU канала задает различные типы PDUs, который может быть передан на закодированном PHY BLE. Эта таблица сопоставляет различные типы PDUs с физическими каналами и ФИЗИКОЙ, на которой может появиться пакет BLE. Таблица также показывает режимы передачи PHY, поддержанные для каждого типа рекламы физического PDU канала.
| Тип PDU | Имя PDU | Физический канал | LE 1M поддержка | LE 2M поддержка | LE закодированная поддержка |
|---|---|---|---|---|---|
0000b | ADV_IND | Первичная реклама | Да | ||
0001b | ADV_DIRECT_IND | Первичная реклама | Да | ||
0010b | ADV_NONCONN_IND | Первичная реклама | Да | ||
0011b | SCAN_REQ | Первичная реклама | Да | ||
AUX_SCAN_REQ | Вторичная реклама | Да | Да | Да | |
0100b | SCAN_RSP | Первичная реклама | Да | ||
0101b | CONNECT_IND | Первичная реклама | Да | ||
AUX_CONNECT_REQ | Вторичная реклама | Да | Да | Да | |
0110b | ADV_SCAN_IND | Первичная реклама | Да | ||
0111b | ADV_EXT_IND | Первичная реклама | Да | Да | |
AUX_ADV_IND | Вторичная реклама | Да | Да | Да | |
AUX_SCAN_RSP | Вторичная реклама | Да | Да | Да | |
AUX_SYNC_IND | Периодический | Да | Да | Да | |
AUX_CHAIN_IND | Вторичная реклама и периодический | Да | Да | Да | |
1000b | AUX_CONNECT_RSP | Вторичная реклама | Да | Да | Да |
| Все другие значения | Зарезервированный для будущего использования | ||||
Поле RFU резервируется для будущего использования. ChSel, TxAdd, и RxAdd поля рекламного физического заголовка PDU канала содержат информацию, характерную для типа PDU, заданного для каждого рекламного физического PDU канала отдельно. Если ChSel, TxAdd, или RxAdd поля не заданы столь же используемые в данном PDU, затем они рассматриваются, как зарезервировано для будущего использования.
Length поле рекламного физического заголовка PDU канала обозначает длину полезной нагрузки в октетах. Допустимая область значений поля Length является 1 - 255 октетами.
Payload поле в рекламной физической пакетной структуре PDU канала характерно для типа PDUs, перечисленного в предыдущей таблице.
Для получения дополнительной информации о рекламе физического канала PDUs, смотрите объем 6, Часть B, Раздел 2.3 из Спецификации [2] Ядра Bluetooth.
Пакетный формат структуры данных физический PDU канала показывают в этом рисунке.
Данные физический PDU канала имеет 16-битный или 24-битный заголовок, полезную нагрузку переменной длины в области значений [0, 251] октеты, и может включать 32-битное поле проверки целостности сообщения (MIC). MIC не включен в незашифрованную связь LL или в зашифрованную связь LL с PDU канала данных, содержащим пустую полезную нагрузку. MIC включен в зашифрованную связь LL с PDU канала данных, содержащим ненулевую полезную нагрузку длины. В этом случае MIC вычисляется, как задано в объеме 6, Часть E, Раздел 1 из Спецификации [2] Ядра Bluetooth.
Поле заголовка данные физический PDU канала показывают в этом рисунке.
Данные физический заголовок PDU канала включают эти поля:
Соедините идентификатор слоя (LLID) — Это поле указывает, является ли пакет PDU данных LL или PDU управления LL.
00b — Зарезервированный для будущего использования
01b — PDU Данных LL, который может быть фрагментом продолжения управления логической ссылкой и адаптации (L2CAP) сообщение или пустой PDU
10b — PDU Данных LL, который может быть запуском сообщения L2CAP или полного сообщения L2CAP без фрагментации
11b — LL управляют PDU
Затем ожидаемый порядковый номер (NESN): LL использует это поле, чтобы или подтвердить последние данные физический PDU канала, отправленный коллегой или запросить коллегу снова послать последние данные физический PDU канала. Для получения дополнительной информации о NESN, смотрите объем 6, Часть B, Раздел 4.5.9 из Спецификации [2] Ядра Bluetooth.
Порядковый номер (SN): LL использует это поле, чтобы идентифицировать пакеты BLE, отправленные им. Для получения дополнительной информации о SN, смотрите объем 6, Часть B, Раздел 4.5.9 из Спецификации [2] Ядра Bluetooth.
Больше данных (MD): Это поле указывает, что устройство BLE имеет больше данных, чтобы отправить. Если ни одно из основного и ведомого устройства BLE не установило бит MD в их пакетах, пакет от ведомого устройства закрывает событие связи. Если ведущие и ведомые устройства установили бит MD, ведущее устройство может продолжить событие связи путем отправки другого пакета, и ведомое устройство должно послушать после отправки его пакета. Для получения дополнительной информации о MD, смотрите объем 6, Часть B, Раздел 4.5.6 из Спецификации [2] Ядра Bluetooth.
Подарок CTEInfo (CP): Это поле указывает, имеют ли данные, физический заголовок PDU канала имеет поле CTEInfo и, впоследствии ли данные физический пакет канала CTE. Для получения дополнительной информации о пакетной структуре поля CTEInfo, смотрите объем 6, Часть B, Раздел 2.5.2 из Спецификации [2] Ядра Bluetooth.
Длина: Это поле указывает на размер, в октетах, полезной нагрузки и MIC, если существующий. Размер этого поля находится в области значений [0, 255] октеты.
CTEInfo: Это поле указывает на тип и длину CTE.
Два типа данных физический канал PDUs: PDU Данных LL и PDU Управления LL.
PDU Данных LL. LL использует PDU данных LL, чтобы отправить данные L2CAP. Поле LLID в заголовке PDU канала данных LL установлено в любой 01b или 10b. PDU данных LL упоминается как пустой PDU если
Поле LLID заголовка PDU канала данных LL установлено в 01b.
Поле Length заголовка PDU канала данных LL установлено в 00000000b.
PDU данных LL с полем LLID в наборе заголовка к 10b не установили поле Length на 00000000b.
PDU Управления LL. LL использует PDU данных LL, чтобы управлять связью LL. Если поле LLID данных физический заголовок PDU канала установлено в 11b, данные физический PDU канала содержат PDU управления LL. Этот рисунок показывает полезную нагрузку PDU управления LL.
Поле Opcode задает различные типы управления LL PDUs как показано в этой таблице.
| Код операции | PDU управления LL |
|---|---|
0x00 | LL_CONNECTION_UPDATE_IND |
0x01 | LL_CHANNEL_MAP_IND |
0x02 | LL_TERMINATE_IND |
0x03 | LL_ENC_REQ |
0x04 | LL_ENC_RSP |
0x05 | LL_START_ENC_REQ |
0x06 | LL_START_ENC_RSP |
0x07 | LL_UNKNOWN_RSP |
0x08 | LL_FEATURE_REQ |
0x09 | LL_FEATURE_RSP |
0x0A | LL_PAUSE_ENC_REQ |
0x0B | LL_PAUSE_ENC_RSP |
0x0C | LL_VERSION_IND |
0x0D | LL_REJECT_IND |
0x0E | LL_SLAVE_FEATURE_REQ |
0x0F | LL_CONNECTION_PARAM_REQ |
0x10 | LL_CONNECTION_PARAM_RSP |
0x11 | LL_REJECT_EXT_IND |
0x12 | LL_PING_REQ |
0x13 | LL_PING_RSP |
0x14 | LL_LENGTH_REQ |
0x15 | LL_LENGTH_RSP |
0x16 | LL_PHY_REQ |
0x17 | LL_PHY_RSP |
0x18 | LL_PHY_UPDATE_IND |
0x19 | LL_MIN_USED_CHANNELS_IND |
0x1A | LL_CTE_REQ |
0x1B | LL_CTE_RSP |
0x1C | LL_PERIODIC_SYNC_IND |
0x1D | LL_CLOCK_ACCURACY_REQ |
0x1E | LL_CLOCK_ACCURACY_RSP |
Все другие значения | Зарезервированный для будущего использования |
Поле CtrData в PDU управления LL характерно для значения поля Opcode. Для получения дополнительной информации о различном LL управляйте PDUs и их соответствующей структурой поля CtrData, смотрите объем 6, Часть B, Разделы 2.4.2.1 к 2.4.2.28 из Спецификации [2] Ядра Bluetooth.
Длина CTE является переменной и в области значений [16, 160] µs. Это поле содержит постоянно модулируемый ряд 1 с без отбеливания прикладного. CTE имеет два типа: антенна, переключающаяся во время передачи CTE (AoD) и антенны, переключающейся во время приема CTE (AoA). При получении пакета, содержащего AoD CTE, получатель не должен переключать антенны. При получении пакета, содержащего AoA CTE, получатель выполняет антенну, переключающуюся на уровне и согласно переключающемуся шаблону, сконфигурированному хостом. В обоих случаях получатель берет выборку IQ в каждую микросекунду во время отчетного периода и выборку IQ каждый демонстрационный паз. Диспетчер сообщает о выборках IQ хосту. Получатель производит целый CTE независимо от своей длины, если это не конфликтует с другими действиями. Для получения дополнительной информации о CTE, смотрите объем 6, Часть B, Разделы 2.5.1 к 2.5.3 из Спецификации [2] Ядра Bluetooth.
Когда требуется хостом, получатель выполняет выборку IQ при получении допустимого пакета BLE с CTE. Однако при получении пакета BLE с CTE и неправильным CRC, получатель может выполнить выборку IQ. Для получения дополнительной информации о выборке IQ, смотрите объем 6, Часть B, Раздел 2.5.4 из Спецификации [2] Ядра Bluetooth.
Для получения дополнительной информации о данных физический канал PDUs, смотрите объем 6, Часть B, Раздел 2.4 из Спецификации [2] Ядра Bluetooth.
Порядок битов в Bluetooth пакеты BR/EDR следует за тем же форматом как Порядок битов в Пакетах BLE.
Bluetooth устройства BR/EDR использует форматы пакета в: Режим BR, Режим EDR, Код доступа, Пакетный Заголовок, Пакетные Типы и Формат Полезной нагрузки.
Для получения дополнительной информации о Bluetooth пакетная структура BR/EDR, смотрите объем 2, Часть B, Раздел 6 из Спецификации [2] Ядра Bluetooth.
Режим BR. Общий формат пакетов BR Bluetooth показывают в этом рисунке. Каждый пакет состоит из этих полей: код доступа (68 или 72 бита), заголовок (54 бита) и полезная нагрузка в области значений [0, 2790] биты.
Спецификация [2] Ядра Bluetooth задает различные типы пакетов. Пакет может состоять из:
Сокращенный код доступа только
Код доступа и пакетный заголовок
Код доступа, пакетный заголовок и полезная нагрузка
Режим EDR. Общий формат Bluetooth пакеты EDR показывают в этом рисунке.
Формат и модуляция кода доступа и пакетных полей заголовка похожи на тот из пакетов BR. После поля заголовка пакеты EDR имеют защитное время в области значений [4.75, 5.25] µs, синхронизирующая последовательность (11 мкс), полезная нагрузка в области значений [0, 2790] биты и трейлер (два символа) поля.
Каждый пакет запускается с кода доступа. Если пакетный заголовок следует, код доступа 72 бита длиной. В противном случае длина кода доступа составляет 68 битов. В этом случае код доступа упоминается как shortened access code. Сокращенный код доступа не содержит трейлер. Код доступа используется в синхронизации, компенсации смещения DC и идентификации всех пакетов, которыми обмениваются на физическом канале. Сокращенный код доступа используется в разбивке на страницы и запросе. В этом случае сам код доступа используется в качестве сообщения передачи, и ни заголовок, ни полезная нагрузка не присутствуют. Этот рисунок показывает пакетную структуру кода доступа.
Различные типы кода доступа используют отличающийся, ниже обращаются к частям (ПОЛИРОВКИ), чтобы создать синхронизирующее слово. Сводные данные различных типов кода доступа показывают в этой таблице.
| Тип кода доступа | LAP | Длина кода доступа (биты) | Описание |
|---|---|---|---|
| Код доступа к каналу (CAC) | Ведущее устройство | 72 | Этот код доступа используется в состоянии связи, синхронизация обучают подсостояние и подсостояние сканирования синхронизации. Это выведено из LAP |
| Код доступа к устройствам (DAC) | Разбитое на страницы устройство | 68 или 72 | Этот код доступа используется во время страницы, сканирования страницы и подсостояний ответа страницы. Это выведено из |
| Специализированный код доступа запроса (DIAC) | Специализированный | 68 или 72 | Этот код доступа используется в подсостоянии запроса в специализированных операциях запроса. |
| Код доступа справки по общим вопросам (GIAC) | Зарезервированный | 68 или 72 | Этот код доступа используется в подсостоянии запроса в операциях справки по общим вопросам. |
Для DAC, DIAC и типов кода доступа GIAC, длина кода доступа 72 битов используется только в сочетании с пакетами последовательности скачкообразного движения частоты (FHS). Когда используется в качестве автономных сообщений без заголовка, DAC, DIAC и GIAC не включают биты трейлера и - длины 68 битов.
CAC состоит из преамбулы, синхронизирующего слова и трейлера.
Преамбула: Это - фиксированный шаблон с 4 символами 1 с и 0s, который упрощает компенсацию DC. Если LSB следующего синхронизирующего слова является 1 или 0, последовательностью преамбулы является 1010 или 0101 (в порядке передачи), соответственно.
Синхронизирующее слово: Это - 64-битная кодовая комбинация, выведенная из 24-битного адреса LAP. Конструкция гарантирует большое Расстояние Хемминга между синхронизирующими словами на основе различных ПОЛИРОВОК. Свойства автокорреляции синхронизирующего слова улучшают приобретение синхронизации.
Трейлер: Это добавлено к синхронизирующему слову, как только пакетный заголовок следует за кодом доступа. Трейлер является фиксированным шаблоном с 4 символами 1 с и 0s. Трейлер вместе с тремя MSBs синхронизирующей словоформы 7-битный шаблон чередования 1 с и 0s, который используется в расширенной компенсации DC. Последовательностью трейлера является любой 1010 или 0101 (в порядке передачи) в зависимости от того, является ли MSB синхронизирующего слова 0 или 1, соответственно.
Для получения дополнительной информации о коде доступа в Bluetooth BR/EDR, смотрите объем 2, Часть B, Раздел 6.3 из Спецификации [2] Ядра Bluetooth.
Структуру пакетного заголовка BR/EDR Bluetooth показывают в этом рисунке.
Эта таблица предоставляет краткое описание о пакетных полях заголовка.
| Пакетное поле заголовка | Размер поля (биты) | Описание |
|---|---|---|
| Логический транспортный адрес (LT_ADDR) | 3 | Это поле указывает на целевое ведомое устройство (устройства) для пакета в пазе передачи ведущего устройства к ведомому устройству и указывает на исходное ведомое устройство для паза передачи ведомого устройства ведущего устройства. |
| Ввод | 4 | Это поле задает тип используемого пакета. Спецификация [2] Ядра Bluetooth задает 16 различных типов пакетов BR/EDR. Значение в этом поле зависит от значения поля LT_ADDR в пакете. Это поле определяет количество пазов, занятых текущим пакетом. |
| Управление потоками (FLOW) | 1 | Это поле реализует управление потоками пакетов BR/EDR по транспорту асинхронного с установлением соединения логического (ACL). Когда получить буфер для ACL, логический транспорт полон, 'ОСТАНОВИТЬ' индикация (FLOW = 0) возвращен, чтобы мешать другому устройству передать данные временно. Когда получить буфер может принять данные, 'ПОЙТИ' индикация (FLOW = 1) возвращена. |
| Автоматический повторный номер запроса (ARQN) | 1 | Это поле сообщает источнику успешной передачи данных о полезной нагрузке с CRC. Это поле резервируется для будущего использования на ведомой широковещательной передаче без установления соединения (CSB) логический транспорт. |
| Порядковый номер (SEQN) | 1 | Это поле предоставляет последовательную схему нумерации заказать пакетный поток данных. Это поле резервируется для будущего использования на логическом транспорте CSB. |
| Проверка на ошибки заголовка (HEC) | 8 | Это поле проверяет пакетную целостность заголовка. Прежде, чем сгенерировать HEC, генератор HEC инициализируется 8-битным значением. Эти 8 битов соответствуют верхней части адреса (UAP). После инициализации генератор HEC вычисляет значение HEC для 10 битов заголовка. Прежде, чем проверять HEC, получатель инициализирует схему проверки HEC соответствующим 8-битным UAP. Если HEC не проверяет пакетную целостность заголовка, целый пакет отбрасывается. |
Для получения дополнительной информации о пакетном заголовке, используемом в Bluetooth BR/EDR, смотрите объем 2, Часть B, Раздел 6.4 из Спецификации [2] Ядра Bluetooth.
Пакеты, используемые в piconet, связаны с этими логическими транспортами, на которых они используются.
Синхронный с установлением соединения (SCO): Это - переключенная в схему связь, которая зарезервировала пазы между ведущим устройством и определенным ведомым устройством.
Расширенный SCO (eSCO): Подобно SCO это резервирует пазы между ведущим устройством и определенным ведомым устройством. eSCO поддерживает окно повторной передачи после зарезервированных пазов. Вместе, зарезервированные пазы и окно повторной передачи формируют полное eSCO окно.
ACL: Это обеспечивает связь с пакетной коммутацией между ведущим устройством и всеми активными ведомыми устройствами, участвующими в piconet. ACL поддерживает асинхронные и изохронные сервисы. Между ведущим устройством и ведомым устройством, только один ACL должен существовать логический транспорт.
CSB: Это используется, чтобы транспортировать широковещательные данные о профиле от ведущего устройства к нескольким ведомым устройствам. Логический транспорт CSB ненадежен.
Эта таблица суммирует пакеты, заданные для SCO, eSCO, ACL и логических транспортных типов CSB.
Записи столбца, сопровождаемые "D", означают поле данных только. "C.1" подразумевает, что значение MIC обязательно, когда шифрование с AES-CCM включено. В противном случае MIC исключен. Для получения дополнительной информации о различных пакетных типах, используемых в Bluetooth BR/EDR, смотрите объем 2, Часть B, Разделы 6.5 и 6.7 из Спецификации [2] Ядра Bluetooth.
| Пакетный тип | ВВЕДИТЕ код | Заполнение паза | Заголовок полезной нагрузки (байты) | Пользовательская полезная нагрузка (байты) | FEC | MIC | CRC | Логические транспортные поддерживаемые типы |
|---|---|---|---|---|---|---|---|---|
| ID | Нет данных | 1 | Нет данных | Нет данных | Нет данных | Нет данных | Нет данных | Нет данных |
| Пустой указатель | 0000 | 1 | Нет данных | Нет данных | Нет данных | Нет данных | Нет данных | SCO, eSCO, ACL, CSB |
| ОПРОС | 0001 | 1 | Нет данных | Нет данных | Нет данных | Нет данных | Нет данных | SCO, eSCO, ACL |
| FHS | 0010 | 1 | Нет данных | 18 | 2/3 | Нет данных | Да | SCO, ACL |
| DM1 | 0011 | 1 | 1 | 0-17 | 2/3 | C1 | Да | SCO, ACL, CSB |
| DH1 | 0100 | 1 | 1 | 0-27 | Нет | C1 | Да | ACL, CSB |
| DM3 | 1010 | 3 | 2 | 0-121 | 2/3 | C1 | Да | ACL, CSB |
| DH3 | 1011 | 3 | 2 | 0-183 | Нет | C1 | Да | ACL, CSB |
| DM5 | 1110 | 5 | 2 | 0-224 | 2/3 | C1 | Да | ACL, CSB |
| DH5 | 1111 | 5 | 2 | 0-339 | Нет | C1 | Да | ACL, CSB |
| 2-DH1 | 0100 | 1 | 2 | 0-54 | Нет | C1 | Да | ACL, CSB |
| 2-DH3 | 1010 | 3 | 2 | 0-367 | Нет | C1 | Да | ACL, CSB |
| 2-DH5 | 1110 | 5 | 2 | 0-679 | Нет | C1 | Да | ACL, CSB |
| 3-DH1 | 1000 | 1 | 2 | 0-83 | Нет | C1 | Да | ACL, CSB |
| 3-DH3 | 1011 | 3 | 2 | 0-552 | Нет | C1 | Да | ACL, CSB |
| 3-DH5 | 1111 | 5 | 2 | 0-1021 | Нет | C1 | Да | ACL, CSB |
| HV1 | 0101 | 1 | Нет данных | 10 | 1/3 | Нет | Нет | SCO |
| HV2 | 0110 | 1 | Нет данных | 20 | 2/3 | Нет | Нет | SCO |
| HV3 | 0111 | 1 | Нет данных | 30 | Нет | Нет | Нет | SCO |
| DV | 1000 | 1 | 1 D | 10 + (0-9) D | 2/3 D | Нет | Да D | SCO |
| EV3 | 0111 | 1 | Нет данных | 1-30 | Нет | Нет | Да | eSCO |
| EV4 | 1100 | 3 | Нет данных | 1-120 | 2/3 | Нет | Да | eSCO |
| EV5 | 1101 | 3 | Нет данных | 1-180 | Нет | Нет | Да | eSCO |
| 2-EV3 | 0110 | 1 | Нет данных | 1-60 | Нет | Нет | Да | eSCO |
| 2-EV5 | 1100 | 3 | Нет данных | 1-360 | Нет | Нет | Да | eSCO |
| 3-EV3 | 0111 | 1 | Нет данных | 1-90 | Нет | Нет | Да | eSCO |
| 3-EV5 | 1101 | 3 | Нет данных | 1-540 | Нет | Нет | Да | eSCO |
Базовая Спецификация [2] Buetooth задает два типа форматов поля полезной нагрузки: синхронное поле данных (для пакетов ACL) и асинхронное поле данных (для SCO и eSCO пакетов). Однако пакеты DV содержат и синхронные и асинхронные поля данных.
Синхронное поле данных: В SCO, который поддерживает только режим BR, фиксируется длина синхронного поля данных. Синхронное поле данных содержит только синхронный фрагмент тела данных и не имеет заголовка полезной нагрузки. В BR eSCO синхронное поле данных состоит из этих двух сегментов: синхронное тело данных и код CRC. В этом случае никакой заголовок полезной нагрузки не присутствует. В EDR eSCO синхронное поле данных состоит из защитного времени, последовательности синхронизации, синхронного тела данных, кода CRC и трейлера. В этом случае никакой заголовок полезной нагрузки не присутствует.
Асинхронное поле данных: пакеты ACL BR имеют асинхронное поле данных, состоящее из заголовка полезной нагрузки, тела полезной нагрузки, MIC (если применимо) и CRC (если применимо). Этот рисунок показывает 8-битный формат заголовка полезной нагрузки для пакетов ACL одно паза BR.
Пакеты ACL EDR имеют асинхронное поле данных, состоящее из защитного времени, последовательности синхронизации, заголовка полезной нагрузки, тела полезной нагрузки, MIC (если применимо), CRC (если применимо) и трейлер. Этот рисунок показывает 16-битный формат заголовка полезной нагрузки для пакетов ACL мультипаза EDR.
Для получения дополнительной информации о формате полезной нагрузки, смотрите объем 2, Часть B, Разделы 6.6.1 и 6.6.2 из Спецификации [2] Ядра Bluetooth.
[1] Технологический Веб-сайт Bluetooth. “Технологический Веб-сайт Bluetooth | официальный сайт Технологии Bluetooth”. Полученный доступ 22 ноября 2019. https://www.bluetooth.com/.
[2] Специальная группа (SIG) Bluetooth. "Спецификация Ядра Bluetooth". Версия 5.1. https://www.bluetooth.com/.
