Bluetooth v4.2: что же действительно нового и как это работает?

Здравствуйте.

3 декабря 2014 года Bluetooth SIG официально анонсировала спецификацию bluetooth версии 4.2.

В пресс-релизе указаны 3 главных нововведения:

• увеличение скорости приема-передачи данных;


• возможность подключения к интернету;


• улучшение конфиденциальности и безопасности.

Главный тезис пресс-релиза: версия 4.2 — идеальна для интернета вещей (IoT).

В этой статье я хочу рассказать, как реализованы эти 3 пункта. Кому интересно добро пожаловать.

Все, что описано ниже, относится только к BLE, поехали…

1. Увеличение скорости приема-передачи пользовательских данных.

Самым главным недостатком у BLE была малая скорость передачи данных. Хотя с какой стороны посмотреть, ведь изначально BLE придумывали ради сохранения энергии источника, питающего устройство. А чтобы беречь энергию, надо с перерывами выходить на связь и передавать немного данных. Однако, все равно, весь интернет заполнен возмущениями о малой скорости и вопросами о возможности ее увеличения, а также увеличения размера передаваемых данных.

И вот с появлением версии 4.2, Bluetooth SIG заявил об увеличении скорости передачи в 2,5 раза и размера передаваемого пакета в 10 раз. Как же они этого добились?

Сражу скажу, что эти 2 цифры связаны друг с другом, а именно: скорость увеличилась потому, что увеличился размер передаваемого пакета.

Посмотрим на PDU (protocol data unit) канала данных:



Каждый PDU содержит 16-ти битный заголовок (header). Так вот, этот заголовок в версии 4.2 отличается от заголовка в версии 4.1.

Вот заголовок версии 4.1:



А вот заголовок версии 4.2:



Примечание: RFU (Reserved for Future Use) — поле, обозначенное этой аббревиатурой зарезервировано для будущего использования и заполняется нулями.

Как мы видим, последние 8 бит заголовка отличаются. Поле «Lenght» — это сумма длин полезных данных и поля MIC (Message Integrity Check), находящегося в PDU (если последнее включено).

Если в версии 4.1 поле «Lenght» имеет размер 5 бит, то в версии 4.2 это поле размером 8 бит.

Отсюда несложно вычислить, что поле «Lenght» в версии 4.1 может содержать значения в промежутке от 0 до 31, а в версии 4.2 в промежутке от 0 до 255. Если из максимальных значений вычесть длину поля MIC (4 октета), то получим, что полезных данных может быть 27 и 251 октет для версии 4.1 и 4.2 соответственно. На самом деле максимальное кол-во данных еще меньше, т.к. в полезной нагрузке находятся еще и служебные данные L2CAP (4 октета) и ATT (3 октета), но это мы рассматривать не будем.

Таким образом размер передаваемых пользовательских данных увеличился приблизительно в 10 раз. Что же касается скорости, которая, почему-то, увеличилась на в 10 раз, а всего в 2.5 раза, то тут нельзя говорить о пропорциональном увеличении, потому, что все упирается еще и в гарантированность доставки данных, ведь гарантировать доставку 200 байт немного сложнее чем 20-ти.

2. Возможность подключения к интернету.

Пожалуй, самое интересное нововведение, из-за которого Bluetooth SIG и объявила, что версия 4.2 делает интернет вещей (IoT) лучше именно благодаря этой возможности.

Еще в версии 4.1 в L2CAP появился режим «LE Credit Based Flow Control Mode». Этот режим позволяет управлять потоком данных, используя т.н. схему, основанную на кредите. Особенность схемы в том, что она не использует сигнальные пакеты, для обозначения кол-ва передаваемых данных, а запрашивает у другого устройства кредит на определенный объем данных для передачи, тем самым ускоряя процесс передачи. При этом, принимающая сторона каждый раз при получении фрейма, уменьшает счетчик фреймов, и при достижении последнего фрейма может разорвать соединение.

В списке команд L2CAP появилось 3 новых кода:

— LE Credit Based Connection request – запрос на соединение по схеме кредита;

— LE Credit Based Connection response – ответ на соединение по схеме кредита;

— LE Flow Control Credit – сообщение о возможности получить дополнительные LE-кадры.

В пакете «LE Credit Based Connection request»



есть поле «Initial Credits» длиной в 2 октета, указывающее на кол-во LE-фреймов, которое устройство может отправить на уровне L2CAP.

В ответном пакете «LE Credit Based Connection response»



в том же поле указано кол-во LE-фреймов, которое может отправить другое устройство, а также в поле «Result» указан результат запроса на соединение. Значение 0x0000 говорит об успехе, остальные значения указывают на ошибку. В частности, значение 0x0004 указывает на отказ в соединении из-за отсутствия ресурсов.

Таким образом уже в версии 4.1 появилась возможность передачи большого кол-ва данных на уровне L2CAP.

И вот, практически одновременно с выходом версии 4.2, публикуется:

Главным требованием профиля для уровня L2CAP является «LE Credit Based Connection» появившееся в версии 4.1, которое, в свою очередь позволяет передавать пакеты с MTU >= 1280 октетов (надеюсь намек на цифру понятен).

Профиль определяет следующие роли:

— роль маршрутизатора (Router) – используется для устройств, которые могут маршрутизировать IPv6 пакеты;

— роль узла (Node) – используется для устройств, которые могу только принимать или отправлять пакеты IPv6; имеют функцию обнаружения сервисов и имеют сервис IPSS, позволяющий маршрутизаторам обнаруживать данное устройство;

Устройства с ролью маршрутизатора, которым необходимо подключение к другому маршрутизатору могут иметь роль узла.

Как ни странно, но передача пакетов IPv6 не является частью спецификации профиля, и указывается в IETF RFC «Transmission of IPv6 packets over Bluetooth Low Energy». В этом документе опредлен еще один интересный момент, а именно то, что при передаче пакетов IPv6 используется стандарт 6LoWPAN — это стандарт взаимодействия по протоколу IPv6 поверх маломощных беспроводных персональных сетей стандарта IEE 802.15.4.

Посмотрите на рисунок:



В профиле определено, что IPSS, GATT и ATT используются только для обнаружения сервиса, а GAP используется только для обнаружения устройства и установки соединения.

А вот выделенное красным, как раз говорит о том, что передача пакетов не входит в спецификацию профиля. Это позволяет программисту написать свою реализацию передачи пакетов.

3. Улучшение конфиденциальности и безопасности.

Одной из обязанностей менеджера безопасности (Sequrity manager) (SM) является сопряжение двух устройств. В процессе сопряжения создаются ключи, которые затем используются для шифрования связи. Процесс сопряжения состоит из 3-х фаз:

• обмен информацией о способах сопряжения;


• генерация краткосрочных ключей (Short Term Key (STK));


• обмен ключами.

В версии 4.2 2-я фаза разделилась на 2 части:

• генерация краткосрочных ключей (Short Term Key (STK)) под названием «LE legacy pairing»


• генерация долговременных ключей (Long Term Key (LTK)) под названием «LE Secure Connections»

А 1-я фаза добавилась еще одним способом сопряжения: «Numeric Comparison» который работает только со вторым вариантом 2-й фазы: «LE Secure Connections».

В связи с этим в криптографическом тулбоксе менеджера безопасности помимо 3-х существующих функций, появилось еще 5 и эти 5 используются только для обслуживания нового процесса сопряжения «LE Secure Connections». Эти функции генерируют:

• LTK и MacKey;


• подтверждающие переменные;


• переменные проверки аутентификации;


• 6-ти значные числа, используемые для отображения на связываемых устройствах.

Все функции используют алгоритм шифрования AES-CMAC с 128-ми битным ключом.

Так вот, если при сопряжении во 2-й фазе по методу «LE legacy pairing» генерировалось 2 ключа:

• Temporary Key (TK): 128-ми битный временный ключ, используемый для генерации STK;


• Short Term Key (STK): 128-ми битный временный ключ, используемый для шифрования соединениЯ

то по методу «LE Secure Connections» генерируется 1 ключ:

• Long Term Key (LTK): 128-ми битный ключ, используемый для шифрования последующих соединениЙ.

Результатом этого нововведения мы получили:

• предотвращение отслеживания, т.к. теперь за счет «Numeric Comparison» есть возможность контролировать возможность подключения к Вашему устройству.


• улучшение энерго-эффективности, т.к. теперь не требуется дополнительная энергия для повторных генераций ключей при каждом соединении.


• отраслевой стандарт шифрования для обеспечения конфиденциальных данных.

Как это ни странно звучит, но за счет улучшения безопасности мы получили улучшение энерго-эффективности.

4. Есть ли уже возможность пощупать?

Да, есть.

NORDIC Semiconductor выпустил «nRF51 IoT SDK» который включает в себя стек, библиотеки, примеры и API для устройств серии nRF51. Сюда входят:

• чипы nRF51822 и nRF51422;


• nRF51 DK;


• nRF51 Dongle;


• nRF51822 EK.

По ссылке можно загрузить:

• краткое описание;


• архив с описанным SDK;


• архив ядра для Raspberry Pi, включая его исходники.

5. Заключение.

Самым ожидаемым лично для меня конечно было увеличение скорости передачи и размера пакета передаваемых данных.

В первом квартале 2015 года должны появиться первые чипы, поддерживающие версию 4.2, потом будут обновления мобильных платформ и все это позволит добавлять новые возможности в мир интернет вещей.

Спасибо за внимание.

Recommended article: Chomsky: We Are All – Fill in the Blank.

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.