В Bluetooth Low Energy 4.0 и 4.1 максимальный PDU пакета OTA составляет 39 байт (47 байт с преамбулой, адресом доступа и CRC) и был увеличен до 257 байт в версии 4.2 , Причина короткого пакета - стабильность радио, длинные пакеты нагревают кремний и дополнительную схему, чтобы поддерживать стабильность частоты. Таким образом, в BLE 4.1 самый длинный пакет составляет 376 микросекунд, чтобы избежать эффекта нагрева. Поскольку скорость передачи данных составляет 1 МГц, 376 микросекунд составляет 376 бит = 47 байт, поэтому объясняется размер PDU. Но в версии 4.2 самый длинный пакет - 2120 бит, поэтому 2,12 мс, и я прочитал 3 мс-пакеты в классическом bluetooth, достаточно долго, чтобы вызвать проблемы. Поэтому мой вопрос: почему и как SIG удалось увеличить PDU в версии 4.2, известно, что некоторые полупроводниковые компании заявляют, что оборудование одинаково для всех версий. Что привело к этой новой длине PDU?Объяснение размера PDU в Bluetooth Low Energy 4.2
ответ
В 4. [01], 39 байт - это максимальный размер блока LL PDU, достигнутый для рекламных пакетов (2 байта заголовка, 6 байтов адреса устройства, 31 байт AD). Для пакетов данных максимальный размер PDU составляет 33 байта (2 заголовка + 4 L2CAP + 23 ATT + 4 MIC).
Примечание. Заголовок канала данных подсчитывает размер блока PDU без заголовка, поэтому размер полезной нагрузки канала данных увеличивается до 31 байта. Это число, которое увеличилось в 4.2 (фактическое минимальное значение составляет 27 байтов, если крипто не поддерживается, потому что 4-байтовый MIC никогда не появится в пакете).
Новый канал данных, размер полезной нагрузки определяется в 4.2 является максимально возможным значением протокола может поддерживать, так что это значение поддержка чипа может, а не абсолютный размер пакета каждый чип должен поддерживать.
Фактический размер полезной нагрузки канала данных согласован с LL_LENGTH_REQ и LL_LENGTH_RSP между двумя задействованными радиостанциями. Они могут согласовывать любую длину от 27 до 251 байт (на уровне полезной нагрузки) (см. Core_v4.2 6.B.2.4.2.21).
В первом выпуске спецификации BLE абсолютный максимальный размер пакета был 27 байтов (полезная нагрузка данных без MIC). Spec использовал 5-битное поле для размера пакета LL, еще 3 бита этого байта заголовка были RFU. В итоге он был увеличен до 8 бит с полной обратной совместимостью в 4.2, но в заголовке нет более смежного бита. Для меня это объясняет, почему ограничение составляет около 256 байт (дайте или возьмите из-за фиксированных размеров заголовка, которые не являются частью байта): он дает разумное расширение без значительного изменения протокола.
Спасибо. Я читал спецификации как «обязательно», а не как «могу». – JJM
Ответ только на комментарии о последствиях увеличения размера. Он не рассматривал исходный вопрос «Причина короткого пакета - это стабильность радио, длинные пакеты нагревают кремний и дополнительные схемы, которые необходимо добавить, чтобы поддерживать частоту стабильный ", если это действительно так, как увеличение размера пакета не вызывает эффект нагрева/нестабильность? –
Фактический вопрос: «Почему и как получилось ** SIG ** [...]». Сам ответ - это различие ** может/должно быть **. Эффект зависит от кристалла, и поставщики могут обеспечить ограничение, которое они фактически поддерживают в своих чипах. Даже если чипы были разработаны до 4.2, они могут поддерживать более длинные пакеты в первую очередь, даже если они не могут достичь предела 251 байт. – Nipo