Пакетная структура Bluetooth

Bluetooth® Special Interest Group (SIG) [1] и [2] задает различные пакетные структуры для Bluetooth низкой энергии (BLE) и устройств базовой скорости / улучшенной скорости передачи данных (BR/EDR) Bluetooth.

Пакетная структура BLE

Порядок битов в пакетах BLE

При определении пакетов и сообщений в основополосной спецификации, порядок битов следует за форматом с прямым порядком байтов. В этом формате применяются эти правила:

  • Младший значащий бит (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.

BLE незакодированный физический уровень (PHY)

Спецификация [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 закодировала 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 канала показывают в этом рисунке.

Рекламный физический 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 канала показывают в этом рисунке.

Данные физический 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.

Постоянный тон дополнительная и синфазная квадратура (IQ) выборка

Длина 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

Порядок битов в Bluetooth Пакеты BR/EDR

Порядок битов в 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 BD_ADDR Ведущего устройства .

Код доступа к устройствам (DAC)Разбитое на страницы устройство68 или 72

Этот код доступа используется во время страницы, сканирования страницы и подсостояний ответа страницы. Это выведено из BD_ADDR разбитых на страницы устройств.

Специализированный код доступа запроса (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.

Пакетный типВВЕДИТЕ код Заполнение пазаЗаголовок полезной нагрузки (байты)Пользовательская полезная нагрузка (байты)FECMICCRCЛогические транспортные поддерживаемые типы
IDНет данных1Нет данныхНет данныхНет данныхНет данныхНет данныхНет данных
Пустой указатель00001Нет данныхНет данныхНет данныхНет данныхНет данныхSCO, eSCO, ACL, CSB
ОПРОС00011Нет данныхНет данныхНет данныхНет данныхНет данныхSCO, eSCO, ACL
FHS00101Нет данных182/3Нет данныхДаSCO, ACL
DM10011110-172/3C1 ДаSCO, ACL, CSB
DH10100110-27НетC1 ДаACL, CSB
DM31010320-1212/3C1 ДаACL, CSB
DH31011320-183НетC1 ДаACL, CSB
DM51110520-2242/3C1 ДаACL, CSB
DH51111520-339НетC1 ДаACL, CSB
2-DH10100120-54НетC1 ДаACL, CSB
2-DH31010320-367НетC1 ДаACL, CSB
2-DH51110520-679НетC1 ДаACL, CSB
3-DH11000120-83НетC1 ДаACL, CSB
3-DH31011320-552НетC1 ДаACL, CSB
3-DH51111520-1021НетC1 ДаACL, CSB
HV101011Нет данных101/3НетНетSCO
HV201101Нет данных202/3НетНетSCO
HV301111Нет данных30НетНетНетSCO
DV100011 D10 + (0-9) D2/3 DНетДа DSCO
EV301111Нет данных1-30НетНетДаeSCO
EV411003Нет данных1-1202/3НетДаeSCO
EV511013Нет данных1-180НетНетДаeSCO
2-EV301101Нет данных1-60НетНетДаeSCO
2-EV511003Нет данных1-360НетНетДаeSCO
3-EV301111Нет данных1-90НетНетДаeSCO
3-EV511013Нет данных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/.

Похожие темы

Для просмотра документации необходимо авторизоваться на сайте