Pull to refresh

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

Network technologiesWireless technologies


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

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 бит заголовка отличаются. Поле «Length» — это сумма длин полезных данных и поля MIC (Message Integrity Check), находящегося в PDU (если последнее включено).
Если в версии 4.1 поле «Length» имеет размер 5 бит, то в версии 4.2 это поле размером 8 бит.

Отсюда несложно вычислить, что поле «Length» в версии 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, потом будут обновления мобильных платформ и все это позволит добавлять новые возможности в мир интернет вещей.

Спасибо за внимание.
Tags:bluetoothbluetooth 4.2bluetooth leiot
Hubs: Network technologies Wireless technologies
Total votes 26: ↑26 and ↓0 +26
Views125.8K

Comments 16

Only those users with full accounts are able to leave comments. Log in, please.

Popular right now

Android разработчик (Kotlin) Middle+/Senior
from 130,000 to 270,000 ₽МТСМоскваRemote job
Middle+ React Native Developer
from 3,500 to 4,000 $CodemotionRemote job
Middle+ / Senior Node.js Developer for fintech project
from 3,000 to 4,500 $CodemotionRemote job
Senior Network developer
to 250,000 ₽RunexisМоскваRemote job
Lead Network Developer
to 280,000 ₽RunexisМоскваRemote job

Top of the last 24 hours