Структура пакета Bluetooth
Bluetooth® Special Interest Group (SIG) [1] и [2] задает различные пакетные структуры для устройств Bluetooth с низкой энергией (BLE) и Bluetooth с основной скоростью/улучшенной скоростью передачи данных (BR/EDR).
Структура пакета BLE
Бит Упорядоченного расположения в пакетах BLE
При определении пакетов и сообщений в спецификации baseband упорядоченное расположение битов выполняется в маленьком эндовом формате. В этом формате применяются следующие правила:
Наименее значительный бит (LSB) соответствует b 0.
LSB - первый бит, посылаемый по воздуху.
При иллюстрации структуры пакета LSB показан на левой оси.
Кроме того, поля данных, сгенерированные внутри на уровне основной полосы (заголовок пакета и длина заголовка полезной нагрузки), должны сначала передаваться с LSB. Для примера 3-битный параметр отправляется как: b0b1b2 = 110 по воздуху, где 1 отправляется первым, а 0 отправляется последним.
Устройства BLE используют форматы пакетов для: BLE Uncoded Physical Layer (PHY), BLE Coded PHY, Рекламного физического канала PDU, PDU физического канала данных и расширения постоянного тонального сигнала и синфазной квадратуры (IQ) Samplature
Примечание
Для получения дополнительной информации о структуре пакета BLE смотрите том 6, Часть B, Раздел 2 Спецификации ядра Bluetooth [2].
BLE незакодированный физический слой (PHY)
Спецификация ядра Bluetooth [2] задает два режима передачи физического слоя (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-соединение между любыми двумя устройствами и каждым периодическим рекламным train имеет отдельный адрес доступа. Каждый раз, когда устройству BLE нужен новый адрес доступа, LL генерирует новое случайное значение, соответствующее этим требованиям:
Значение не должно быть адресом доступа для любого существующего LL-соединения на этом устройстве.
Значение не должно быть адресом доступа для любого включенного периодического рекламного train.
Значение должно иметь не более шести последовательных 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+ <reservedrangesplaceholder0> +1.
Для получения дополнительной информации о генерации CRC см. Том 6, Часть B, Раздел 3.1.1 Спецификации ядра Bluetooth [2].
КТЭ. CTE состоит из постоянно модулируемой серии ненужных 1с. Это поле имеет переменную длину в диапазоне от 16 мкс до 160 мкс.
Для получения дополнительной информации о CTE см. том 6, Часть B, Раздел 2.5.1 Спецификации ядра Bluetooth [2].
Примечание
Для получения дополнительной информации о незакодированной структуре пакета PHY BLE см. Том 6, Часть B, Раздел 2,1 Спецификации ядра Bluetooth [2].
BLE-кодирование PHY
Этот рисунок показывает структуру пакета для кодированного 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' (в порядке передачи).
Адрес доступа. Длина адреса доступа PHY с кодировкой BLE составляет 256 символов. Дополнительные сведения см. в разделе Адрес доступа. В дополнение к требованиям, перечисленным в подразделе адреса доступа раздела BLE Uncoded Physical Layer (PHY), новое значение адреса доступа кодированного BLE PHY должно также удовлетворять этим требованиям:
Значение должно иметь не менее трех 1с в последних значимых битах.
Значение должно иметь не более 11 переходов в наименее значимых 16 битах.
КИ. Поле 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 рекламного физического канала показан на этом рисунке.
Рекламный физический канал PDU имеет 16-битный заголовок и полезную нагрузку переменного размера. 16-битное поле заголовка PDU рекламного физического канала показано на этом рисунке.
Поле типа PDU в заголовке PDU рекламного канала задает различные типы PDU, которые могут передаваться по кодированному PHY BLE. Эта таблица отображает различные типы PDU с физическими каналами и PHY, на которых может появиться пакет BLE. Таблица также указывает режимы передачи PHY, поддерживаемые для каждого типа рекламного физического канала PDU.
| Тип PDU | Имя PDU | Физический канал | Поддержка 1M LE | Поддержка 2M LE | 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 зарезервировано для использования в будущем. The ChSel, TxAdd, и RxAdd поля заголовка PDU рекламного физического канала содержат информацию, относящуюся к типу PDU, заданному для каждого PDU рекламного физического канала отдельно. Если на ChSel, TxAdd, или RxAdd поля не определяются как используемые в данном PDU, тогда они считаются зарезервированными для будущего использования.
The Length поле заголовка PDU рекламного физического канала обозначает длину полезной нагрузки в октетах. Допустимая область значений значений в поле Length составляет от 1 до 255 октетов.
The Payload поле в структуре пакета PDU рекламирующего физического канала характерно для типа PDU, перечисленных в предыдущей таблице.
Примечание
Для получения дополнительной информации о рекламе PDU физического канала см. том 6, Часть B, Раздел 2.3 Спецификации ядра Bluetooth [2].
PDU физического канала данных
Формат структуры пакета 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) или пустого PDU10b- 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].
Больше данных (MD): Это поле указывает, что устройство BLE имеет больше данных для отправки. Если ни одно из ведущего и ведомого устройств BLE не установило бит MD в своих пакетах, пакет от ведомого устройства закрывает событие соединения. Если ведущее и ведомое устройства установили бит MD, ведущее устройство может продолжить событие соединения, отправив другой пакет, и ведомое устройство должно прослушать после отправки своего пакета. Для получения дополнительной информации о MD см. Том 6, Часть B, Раздел 4.5.6 Спецификации ядра Bluetooth [2].
CTEInfo присутствует (CP): Это поле указывает, имеет ли заголовок PDU физического канала данных поле CTEInfo и, впоследствии, имеет ли пакет физического канала данных CTE. Для получения дополнительной информации о структуре пакета поля CTEInfo см. том 6, Часть B, Раздел 2.5.2 Спецификации ядра Bluetooth [2].
Длина: Это поле указывает размер, в октетах, полезной нагрузки и MIC, если присутствует. Размер этого поля находится в области значений [0, 255] октетов.
CTEInfo: В этом поле указывается тип и длина CTE.
Два типа PDU физического канала данных: LL Data PDU и LL Control PDU.
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.
LL Control PDU. LL использует PDU данных LL для управления соединением LL. Если для поля LLID заголовка PDU физического канала данных задано значение 11b, PDU физического канала данных содержит 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 в блоке управления LL характерно для значения поля Opcode. Для получения дополнительной информации о различных блоках PDU управления LL и соответствующей структуре полей CtrData см. том 6, Часть B, Разделы 2.4.2.1 - 2.4.2.28 Спецификации ядра Bluetooth [2].
Расширение постоянного тонального сигнала и синфазная квадратурная (IQ) выборка
Длина CTE переменна и находится в области значений [16, 160] мкс. Это поле содержит постоянно модулируемую серию 1с без применения отбеливания. CTE имеет два типа: переключение антенны во время передачи CTE (AoD) и переключение антенны во время приема CTE (AoA). При приеме пакета, содержащего AoD CTE, приемнику не нужно переключать антенны. При приеме пакета, содержащего CTE AoA, приемник выполняет переключение антенны в соответствии с шаблоном переключения, сконфигурированным хостом. В обоих случаях приемник берёт 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
Бит Упорядоченного расположения в пакетах Bluetooth BR/EDR
Упорядоченное расположение бит в пакетах Bluetooth BR/EDR соответствует формату Упорядоченное Расположение в пакетах BLE.
Устройства Bluetooth BR/EDR используют форматы пакетов для: BR Mode, EDR Mode, Access Code, Packet Header, Packet Types и Payload Format.
Примечание
Для получения дополнительной информации о структуре пакета Bluetooth BR/EDR смотрите том 2, Часть B, Раздел 6 Спецификации ядра Bluetooth [2].
Общий формат
Режим BR. Общий формат пакетов Bluetooth BR показан на этом рисунке. Каждый пакет состоит из следующих полей: код доступа (68 или 72 бита), заголовок (54 бита) и полезная нагрузка в области значений [0, 2790] бит.
Спецификация ядра Bluetooth [2] определяет различные типы пакетов. Пакет может состоять из:
Только укороченный код доступа
Код доступа и заголовок пакета
Код доступа, заголовок пакета и полезная нагрузка
Режим EDR. Общий формат пакетов EDR Bluetooth показан на этом рисунке.
Формат и модуляция кода доступа и полей заголовка пакета аналогичны формату пакетов BR. После поля заголовка пакеты EDR имеют защитное время в области значений [4,75, 5,25] мкс, последовательность синхронизации (11 мкс), полезную нагрузку в области значений [0, 2790] битах и поля трейлера (два символа).
Код доступа
Каждый пакет начинается с кода доступа. Если следует заголовок пакета, то код доступа составляет 72 бита. В противном случае длина кода доступа составляет 68 биты. В этом случае код доступа упоминается как shortened access code. Укороченный код доступа не содержит трейлера. Код доступа используется для синхронизации, компенсации смещения постоянного тока и идентификации всех пакетов, обменивающихся по физическому каналу. Укороченный код доступа используется в пейджинге и запросе. В этом случае сам код доступа используется как сообщение сигнализации, и ни заголовок, ни полезная нагрузка не присутствуют. Этот рисунок показывает структуру пакета кода доступа.
Различные типы кода доступа используют различные более низкие части адреса (LAP), чтобы создать слово синхронизации. В этой таблице показаны сводные данные различных типов кода доступа.
| Тип кода доступа | КОЛЕНИ | Длина кода доступа (биты) | Описание |
|---|---|---|---|
| Код доступа к каналу (CAC) | Владелец | 72 | Этот код доступа используется в состоянии соединения, подсостояние обучения синхронизации и подсостояние скана синхронизации. Он получают из LAP Мастер- |
| Код доступа к устройству (DAC) | Пейджинговое устройство | 68 или 72 | Этот код доступа используется во время скана страницы и подсостояний ответа страницы. Он получен из |
| Выделенный код доступа к запросу (DIAC) | Посвященный | 68 или 72 | Этот код доступа используется в подсостоянии запроса для специальных операций запроса. |
| Код доступа к общему запросу (GIAC) | Зарезервировано | 68 или 72 | Этот код доступа используется в подсостоянии запроса для операций общего запроса. |
Для типов кода доступа DAC, DIAC и GIAC, длина кода доступа 72 бита используется только в комбинации с пакетами последовательности скачкообразного изменения частоты (FHS). При использовании в качестве автономных сообщений без заголовка ЦАП, DIAC и GIAC не содержат биты трейлера и имеют длину 68 бит.
CAC состоит из преамбулы, слова синхронизации и трейлера.
Преамбула: Это фиксированный 4-символьный шаблон 1с и 0с, который облегчает компенсацию постоянного тока. Если LSB следующего слова синхронизации
1или0, последовательность преамбулы1010или0101(в порядке передачи), соответственно.Sync word: Это 64-битное кодовое слово, полученное из 24-битного адреса LAP. Конструкция гарантирует большое расстояние Хемминга между синхронизирующими словами на основе различных LAP. Автокорреляционные свойства слова синхронизации улучшают получение синхронизации.
Трейлер: Он добавляется к слову синхронизации, как только заголовок пакета следует за кодом доступа. Трейлер представляет собой фиксированный 4-символьный шаблон размером 1с и 0с. Трейлер вместе с тремя MSB слова синхронизации образует 7-битовый шаблон чередующихся 1с и 0с, который используется для расширенной компенсации постоянного тока. Последовательность трейлеров либо
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' (ПОТОК = 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].
| Тип пакета | ТИП Кода | Заполнение пазов | Заголовок полезной нагрузки (байт) | Полезная нагрузка пользователя (байт) | 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 [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 Technology. Bluetooth Technology Website | Официальный сайт Bluetooth Technology. Доступ к 22 ноября 2019 года. https://www.bluetooth.com/.
[2] Группа специальных интересов Bluetooth (SIG). Bluetooth Core Спецификации. Версия 5.1. https://www.bluetooth.com/.