Bluetooth ® Special Interest Group (SIG) [1] и [2] определяют различные структуры пакетов для устройств Bluetooth с низкой энергией (BLE) и базовой скоростью/повышенной скоростью передачи данных Bluetooth (BR/EDR).
При определении пакетов и сообщений в спецификации базовой полосы порядок битов следует формату little-endian. В этом формате применяются следующие правила:
Младший значащий бит (LSB) соответствует b0.
LSB - первый бит, посылаемый по воздуху.
При иллюстрации структуры пакета LSB показан на левой стороне.
Кроме того, поля данных, сгенерированные внутри на уровне основной полосы частот (заголовок пакета и длина заголовка полезной нагрузки), должны передаваться сначала с LSB. Например, 3-разрядный параметр посылается как: b0b1b2 = 110 по воздуху, где 1 посылается первым, а 0 - последним.
Устройства BLE используют пакетные форматы для: некодированного физического уровня (PHY) BLE, закодированного PHY BLE, PDU рекламного физического канала, PDU физического канала данных, расширения постоянного тона и дискретизации синфазной квадратуры (IQ).
Примечание
Для получения дополнительной информации о структуре пакетов BLE см. том 6, часть B, раздел 2 спецификации ядра Bluetooth [2].
Спецификация ядра Bluetooth [2] определяет два режима передачи на физическом уровне (LE 1M и LE 2M) для некодированного PHY. На этом рисунке показана структура пакетов для некодированного PHY BLE, работающего на 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 с или 0 с.
Значение не должно быть адресом доступа для пакетов рекламных каналов.
Значение не должно быть последовательностью, которая отличается от адреса доступа рекламных пакетов физического канала только на 1 бит.
Все четыре октета для значения не должны быть равны.
Значение должно иметь не менее двух переходов в наиболее значимых 6 битах.
Если случайное значение не удовлетворяет вышеуказанным требованиям, генерируется новое случайное значение до тех пор, пока оно не будет соответствовать всем требованиям.
PDU. Когда пакет BLE передается либо по первичному, либо по вторичному рекламному физическому каналу, либо по периодическому физическому каналу, блок PDU определяется как блок PDU рекламного физического канала. Когда пакет передается по физическому каналу данных, PDU определяется как PDU физического канала данных.
CRC. Размер CRC составляет 3 октета и вычисляется на PDU всех пакетов LL. Если PDU зашифрован, то CRC вычисляется после завершения шифрования PDU. Многочлен CRC имеет вид x24 + x10 + x9 + x6 + x4 + x3 + x + 1.
Для получения дополнительной информации о создании CRC см. том 6, часть B, раздел 3,1,1 спецификации ядра Bluetooth [2].
КТР. CTE состоит из постоянно модулированной серии небеленых 1s. Это поле имеет переменную длину в диапазоне от 16 мкс до 160 мкс.
Для получения дополнительной информации о CTE см. том 6, часть B, раздел 2,5,1 спецификации ядра Bluetooth [2].
Примечание
Для получения дополнительной информации о структуре некодированных пакетов PHY BLE см. том 6, часть B, раздел 2,1 спецификации ядра Bluetooth [2].
На этом рисунке показана структура пакетов для кодированного BLE PHY и реализована для пакетов BLE во всех физических каналах.
Каждый пакет BLE состоит из преамбулы и этих двух блоков прямого исправления ошибок (FEC):
Блок FEC 1 - этот блок содержит три поля: адрес доступа, индикатор кодирования (CI) и TERM1. Этот блок реализует схему кодирования S = 8, где каждый бит представляет восемь символов. Это дает скорость передачи данных 125 кбит/с.
Блок FEC 2 - этот блок содержит три поля: PDU, CRC и TERM2. Этот блок реализует схему кодирования S = 8 или S = 2. В схеме кодирования S = 2 каждый бит представляет два символа. Поэтому скорость передачи данных составляет 500 кбит/с.
Кодированный BLE PHY не содержит CTE.
Преамбула. BLE закодировал преамбулу PHY, 80 символов в длине и содержат 10 повторений образца символа '00111100' (в заказе передачи).
Адрес доступа. Длина кодированного BLE адреса доступа PHY составляет 256 символов. Дополнительные сведения см. в разделе Адрес доступа. В дополнение к требованиям, перечисленным в подразделе адреса доступа раздела некодированного физического уровня (PHY) BLE, новое значение адреса доступа кодированного BLE PHY также должно удовлетворять следующим требованиям:
Значение должно иметь не менее трех 1 с в последних значащих битах.
Значение должно иметь не более 11 переходов в младших 16 разрядах.
CI. Поле CI состоит из двух битов, как показано в этой таблице:
| Биты в CI | Описание |
|---|---|
00b | Блок FEC 2 кодируется с использованием S = 8 |
01b | Блок FEC 2 кодируется с использованием S = 2 |
| Все остальные значения | Зарезервировано для использования в будущем |
PDU. PDU в структуре кодированных PHY пакетов BLE имеет то же форматирование, что и PDU в некодированном PHY пакете BLE.
CRC. CRC в структуре кодированных PHY пакетов BLE имеет то же форматирование, что и CRC в некодированном PHY пакете BLE.
TERM1 и TERM2. Каждый блок FEC содержит признак конца блока. Этот терминатор называется TERM1 и TERM2. Каждый признак конца имеет длину 3 бита и формирует последовательность окончания во время процесса кодирования FEC.
Примечание
Для получения дополнительной информации о структуре пакетов PHY с кодированием BLE см. том 6, часть B, раздел 2,2 спецификации ядра Bluetooth [2].
Формат структуры пакетов блока PDU рекламного физического канала показан на этом рисунке.
Блок PDU рекламного физического канала имеет 16-битный заголовок и полезную нагрузку переменного размера. 16-битовое поле заголовка блока PDU рекламного физического канала показано на этом рисунке.
Поле типа PDU в заголовке PDU рекламного канала определяет различные типы PDU, которые могут передаваться в кодированном BLE PHY. Эта таблица сопоставляет различные типы PDU с физическими каналами и PHY, на которых может появиться пакет 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 | Вторичная реклама | Да | Да | Да |
| Все остальные значения | Зарезервировано для использования в будущем | ||||
Поле РФС зарезервировано для использования в будущем. ChSel, TxAdd, и RxAdd поля заголовка PDU рекламного физического канала содержат информацию, специфичную для типа PDU, определенного для каждого PDU рекламного физического канала отдельно. Если ChSel, TxAdd, или RxAdd поля не определены как используемые в данном PDU, то они считаются зарезервированными для использования в будущем.
Length поле заголовка PDU рекламного физического канала обозначает длину полезной нагрузки в октетах. Допустимый диапазон значений в поле Length составляет от 1 до 255 октетов.
Payload поле в структуре пакетов PDU рекламного физического канала специфично для типа PDU, перечисленных в предыдущей таблице.
Примечание
Для получения дополнительной информации о рекламе PDU физических каналов см. том 6, часть B, раздел 2,3 спецификации ядра Bluetooth [2].
Формат структуры пакетов PDU физического канала данных показан на этом рисунке.
Блок PDU физического канала данных имеет 16-разрядный или 24-разрядный заголовок, полезную нагрузку переменной длины в диапазоне [0, 251] октетов и может включать в себя поле 32-разрядной проверки целостности сообщения (MIC). MIC не включен в незашифрованное соединение LL или в зашифрованное соединение LL с PDU канала данных, содержащим пустую полезную нагрузку. MIC включается в зашифрованное соединение LL с PDU канала данных, содержащим полезную нагрузку ненулевой длины. В этом случае MIC рассчитывается, как указано в томе 6, часть E, раздел 1 спецификации ядра Bluetooth [2].
Поле заголовка блока PDU физического канала данных показано на этом рисунке.
Заголовок PDU физического канала данных включает в себя следующие поля:
Идентификатор канального уровня (LLID) - это поле указывает, является ли пакет PDU данных LL или PDU управления LL.
00b - Зарезервировано для использования в будущем
01b - PDU данных LL, который может быть фрагментом продолжения сообщения управления и адаптации логического канала (L2CAP) или пустым PDU
10b - PDU данных LL, который может быть началом сообщения L2CAP или полным сообщением L2CAP без фрагментации;
11b - PDU управления LL
Следующий ожидаемый порядковый номер (NESN): LL использует это поле либо для подтверждения последнего PDU физического канала данных, отправленного равноправным узлом, либо для запроса однорангового узла на повторную передачу последнего PDU физического канала данных. Для получения дополнительной информации о NESN см. том 6, часть B, раздел 4,5,9 спецификации ядра Bluetooth [2].
Порядковый номер (SN): LL использует это поле для идентификации пакетов BLE, отправленных им. Для получения дополнительной информации о SN см. том 6, часть B, раздел 4,5,9 спецификации ядра Bluetooth [2].
More data (MD): это поле указывает, что устройство BLE имеет больше данных для отправки. Если ни ведущее, ни ведомое устройство BLE не установило бит MD в своих пакетах, пакет от ведомого устройства закрывает событие соединения. Если ведущее и ведомое устройства установили бит MD, ведущее устройство может продолжить событие соединения, отправив другой пакет, и ведомое устройство должно прослушать после отправки своего пакета. Для получения дополнительной информации о MD см. том 6, часть B, раздел 4,5,6 спецификации ядра Bluetooth [2].
CTEInfo present (CP): Это поле указывает, имеет ли заголовок PDU физического канала данных поле CTEInfo, и, впоследствии, имеет ли пакет физического канала данных CTE. Для получения дополнительной информации о структуре пакетов в поле CTEInfo см. том 6, часть B, раздел 2,5,2 спецификации ядра Bluetooth [2].
Длина: это поле указывает размер полезной нагрузки и MIC в октетах, если они имеются. Размер этого поля находится в диапазоне [0, 255] октетов.
CTEInfo: В этом поле указывается тип и длина CTE.
Двумя типами PDU физического канала данных являются 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 физического канала данных установлено значение 11bPDU физического канала данных содержит PDU управления LL. На этом рисунке показана полезная нагрузка PDU управления LL.
Поле Opcode определяет различные типы PDU управления LL, как показано в этой таблице.
| Opcode | 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. Для получения дополнительной информации о различных PDU управления LL и соответствующей структуре полей CtrData см. том 6, часть B, разделы 2,4,2,1- 2,4,2,28 спецификации ядра Bluetooth [2].
Длина КТР является переменной и находится в диапазоне [16, 160] мкс. Это поле содержит постоянно модулированный ряд 1 без применения отбеливания. КТР имеет два типа: переключение антенн при передаче КТР (AoD) и переключение антенн при приеме КТР (AoA). При приеме пакета, содержащего AoD CTE, приемнику не требуется переключать антенны. При приеме пакета, содержащего AoA CTE, приемник выполняет переключение антенны согласно схеме переключения, сконфигурированной хостом. В обоих случаях приемник принимает IQ-выборку в каждую микросекунду в течение опорного периода и IQ-выборку в каждый интервал выборки. Контроллер сообщает выборки IQ хосту. Приемник выполняет выборку всего CTE независимо от его длины, если это не противоречит другим действиям. Для получения дополнительной информации о CTE см. том 6, часть B, разделы 2,5,1- 2,5,3 спецификации ядра Bluetooth [2].
По запросу хоста приемник выполняет IQ-выборку при приеме действительного пакета BLE с CTE. Однако при приеме пакета BLE с CTE и неправильным CRC приемник может выполнить IQ-выборку. Для получения дополнительной информации о выборке IQ см. том 6, часть B, раздел 2,5,4 спецификации ядра Bluetooth [2].
Примечание
Для получения дополнительной информации о PDU физического канала данных см. том 6, часть B, раздел 2,4 спецификации ядра Bluetooth [2].
Порядок битов в пакетах Bluetooth BR/EDR соответствует тому же формату, что и порядок битов в пакетах BLE.
Устройства Bluetooth BR/EDR используют форматы пакетов для: Режим BR, Режим EDR, Код доступа, Заголовок пакета, Типы пакетов и Формат полезной нагрузки.
Примечание
Для получения дополнительной информации о структуре пакетов Bluetooth BR/EDR см. том 2, часть B, раздел 6 спецификации ядра Bluetooth [2].
Режим BR. На этом рисунке показан общий формат пакетов Bluetooth BR. Каждый пакет состоит из следующих полей: код доступа (68 или 72 бита), заголовок (54 бита) и полезная нагрузка в диапазоне [0, 2790] бит.
Спецификация ядра Bluetooth [2] определяет различные типы пакетов. Пакет может состоять из:
Только сокращенный код доступа
Код доступа и заголовок пакета
Код доступа, заголовок пакета и полезная нагрузка
Режим EDR. Общий формат пакетов Bluetooth EDR показан на этом рисунке.
Формат и модуляция кода доступа и полей заголовка пакета аналогичны формату и модуляции пакетов BR. Вслед за полем заголовка пакеты EDR имеют время защиты в диапазоне [4,75, 5,25] мкс, последовательность синхронизации (11 мкс), полезную нагрузку в диапазоне [0, 2790] бит и поля трейлера (два символа).
Каждый пакет начинается с кода доступа. Если следует заголовок пакета, код доступа имеет длину 72 бита. В противном случае длина кода доступа составляет 68 бит. В этом случае код доступа называется сокращенным кодом доступа. Укороченный код доступа не содержит трейлера. Код доступа используется для синхронизации, компенсации смещения 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 с и 0 с, который облегчает компенсацию постоянного тока. Если LSB следующего слова синхронизации имеет значение 1 или 0, последовательность преамбулы 1010 или 0101 (в порядке передачи), соответственно.
Слово синхронизации: это 64-разрядное кодовое слово, полученное из 24-разрядного адреса LAP. Конструкция гарантирует большое расстояние Хэмминга между синхрословами, основанными на различных LAP. Свойства автокорреляции слова синхронизации улучшают получение синхронизации.
Трейлер: Он добавляется к синхронизирующему слову, как только заголовок пакета следует за кодом доступа. Трейлер представляет собой фиксированный 4-символьный шаблон из 1 и 0. Трейлер вместе с тремя MSB синхронизирующего слова образуют 7-битовую комбинацию чередующихся 1 и 0, которая используется для расширенной компенсации DC. Последовательность трейлеров: 1010 или 0101(в порядке передачи) в зависимости от того, является ли MSB слова синхронизации 0 или 1соответственно.
Примечание
Для получения дополнительной информации о коде доступа в Bluetooth BR/EDR см. том 2, часть B, раздел 6,3 спецификации ядра Bluetooth [2].
Структура заголовка пакета Bluetooth BR/EDR показана на этом рисунке.
В этой таблице содержится краткое описание полей заголовка пакета.
| Поле заголовка пакета | Размер поля (биты) | Описание |
|---|---|---|
| Логический транспортный адрес (LT_ADDR) | 3 | В этом поле указывается ведомый узел назначения для пакета в слоте передачи «ведущий-ведомый», а также ведомый узел источника для слота передачи «ведомый-главный ». |
| Напечатать | 4 | В этом поле указывается тип используемого пакета. Спецификация ядра Bluetooth [2] определяет 16 различных типов пакетов BR/EDR. Значение в этом поле зависит от значения LT_ADDR поля в пакете. Это поле определяет количество слотов, занятых текущим пакетом. |
| Управление потоком (FLOW) | 1 | В этом поле реализуется управление потоком пакетов BR/EDR по асинхронному логическому (ACL) транспорту. Когда буфер приема для логического транспорта ACL заполнен, возвращается индикация «STOP» (FLOW = 0), чтобы остановить временную передачу данных другим устройством. Когда буфер приема может принимать данные, возвращается индикация «GO» (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 спецификации ядра Bluetooth [2].
Пакеты, используемые в пикосети, связаны с этими логическими транспортами, на которых они используются.
Синхронное соединение (SCO) - это соединение с коммутацией каналов, которое резервирует слоты между ведущим устройством и определенным ведомым устройством.
Расширенная SCO (eSCO): Аналогично SCO, резервирует слоты между ведущим и конкретным ведомым. eSCO поддерживает окно повторной передачи, следующее за зарезервированными слотами. Вместе зарезервированные слоты и окно повторной передачи образуют полное окно eSCO.
ACL: обеспечивает соединение с коммутацией пакетов между ведущим устройством и всеми активными ведомыми устройствами, участвующими в пикосети. ACL поддерживает асинхронные и изохронные службы. Между ведущим и ведомым устройствами должен существовать только один логический транспорт ACL.
CSB: Он используется для передачи широковещательных данных профиля из главного устройства в несколько подчиненных устройств. Логический транспорт CSB ненадежен.
В этой таблице представлены пакеты, определенные для логических типов транспорта SCO, eSCO, ACL и CSB.
Примечание
Значения столбцов, за которыми следует «D», означают только поле данных. «C.1» означает, что значение MIC является обязательным, когда включено шифрование с помощью AES-CCM. В противном случае MIC исключается. Для получения дополнительной информации о различных типах пакетов, используемых в Bluetooth BR/EDR, см. том 2, часть B, разделы 6,5 и 6,7 спецификации ядра Bluetooth [2].
| Тип пакета | Код TYPE | Занятое место в слоте | Заголовок полезной нагрузки (байт) | Полезная нагрузка пользователя (байт) | FEC | МИКРОМЕТР | CRC | Поддерживаемые логические типы транспорта |
|---|---|---|---|---|---|---|---|---|
| Я бы | Н/Д | 1 | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д |
| ПУСТОЙ УКАЗАТЕЛЬ | 0000 | 1 | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | SCO, eSCO, ACL, CSB |
| ОПРОС | 0001 | 1 | Н/Д | Н/Д | Н/Д | Н/Д | Н/Д | SCO, eSCO, ACL |
| FHS | 0010 | 1 | Н/Д | 18 | 2/3 | Н/Д | Да | SCO, ACL |
| 1 НЕМЕЦКАЯ МАРКА | 0011 | 1 | 1 | 0-17 | 2/3 | C.1 | Да | SCO, ACL, CSB |
| DH1 | 0100 | 1 | 1 | 0-27 | Нет | C.1 | Да | ACL, CSB |
| 3 НЕМЕЦКИХ МАРКИ | 1010 | 3 | 2 | 0-121 | 2/3 | C.1 | Да | ACL, CSB |
| DH3 | 1011 | 3 | 2 | 0-183 | Нет | C.1 | Да | ACL, CSB |
| 5 НЕМЕЦКИХ МАРОК | 1110 | 5 | 2 | 0-224 | 2/3 | C.1 | Да | ACL, CSB |
| DH5 | 1111 | 5 | 2 | 0-339 | Нет | C.1 | Да | ACL, CSB |
| 2-DH1 | 0100 | 1 | 2 | 0-54 | Нет | C.1 | Да | ACL, CSB |
| 2-DH3 | 1010 | 3 | 2 | 0-367 | Нет | C.1 | Да | ACL, CSB |
| 2-DH5 | 1110 | 5 | 2 | 0-679 | Нет | C.1 | Да | ACL, CSB |
| 3-DH1 | 1000 | 1 | 2 | 0-83 | Нет | C.1 | Да | ACL, CSB |
| 3-DH3 | 1011 | 3 | 2 | 0-552 | Нет | C.1 | Да | ACL, CSB |
| 3-DH5 | 1111 | 5 | 2 | 0-1021 | Нет | C.1 | Да | 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 |
Спецификация Buetooth Core Specification [2] определяет два типа форматов полей полезной нагрузки: синхронное поле данных (для пакетов ACL) и асинхронное поле данных (для пакетов SCO и eSCO). Однако пакеты DV содержат как синхронные, так и асинхронные поля данных.
Поле синхронных данных: В SCO, поддерживающем только режим BR, длина поля синхронных данных фиксирована. Поле синхронных данных содержит только часть тела синхронных данных и не имеет заголовка полезной нагрузки. В BR eSCO поле синхронных данных состоит из этих двух сегментов: тела синхронных данных и кода CRC. В этом случае заголовок полезной нагрузки отсутствует. В EDR eSCO поле синхронных данных состоит из защитного времени, последовательности синхронизации, тела синхронных данных, кода CRC и трейлера. В этом случае заголовок полезной нагрузки отсутствует.
Асинхронное поле данных: Пакеты ACL BR имеют асинхронное поле данных, состоящее из заголовка полезной нагрузки, тела полезной нагрузки, MIC (если применимо) и CRC (если применимо). На этом рисунке показан 8-битный формат заголовка полезной нагрузки для однослотовых пакетов ACL BR.
Пакеты EDR ACL имеют асинхронное поле данных, состоящее из защитного времени, последовательности синхронизации, заголовка полезной нагрузки, тела полезной нагрузки, MIC (если применимо), CRC (если применимо) и трейлера. На этом рисунке показан 16-битный формат заголовка полезной нагрузки для пакетов ACL EDR с несколькими слотами.
Примечание
Для получения дополнительной информации о формате полезной нагрузки см. том 2, часть B, разделы 6,6,1 и 6,6,2 спецификации ядра Bluetooth [2].
[1] Веб-сайт технологии Bluetooth. «Веб-сайт Bluetooth Technology | Официальный веб-сайт Bluetooth Technology». Доступно 22 ноября 2019 года. https://www.bluetooth.com/.
[2] Группа специальных интересов Bluetooth (SIG). «Спецификация ядра Bluetooth». Версия 5.1. https://www.bluetooth.com/.