За последнее время количество пользователей мобильных гаджетов значительно увеличилось, а это значит, что большое количество различных технических моментов остаются для начинающих юзеров тёмными лошадками. Одним из таких нюансов и являются Bluetooth-версии.
Протоколы или профили
Вопреки тому, что совместимость bluetooth-версий находится на достаточно высоком уровне, всё-таки иногда случаются ситуации, при которых становится невозможно совершить сопряжение двух устройств. И дело здесь именно в протоколах, а не в профилях. И чтобы обосновать вышеупомянутую невозможность, сперва требуется разобраться, в чём разница между двумя этими понятиями.
Протокол – это набор инструкций, посредством которого и осуществляется передача различной информации. Именно он задаёт порядок, рабочую частоту и длительность работы той или иной составляющей. А профилями называются дополнительные надстройки, которые позволяют оперировать информацией определённого типа. Например, A2DP – это профиль, позволяющий bluetooth-модулю работать со стереозвуком, где при сопряжении происходит также и согласование кодеков, которые будут использоваться.
Если посмотреть в глобальном плане, то версия протоколов имеет большее значение, чем значимость профиля. В случае если оба устройства имеют одинаковую версию протокола, то им будут доступны все стандартные функции и возможности, которые поддерживает модуль. А вот с профилями всё обстоит иначе. Так как они добавляются опционально, чтобы они использовались и работали, потребуется их наличие в обоих гаджетах. Если же лишь один bluetooth -модуль будет поддерживать необходимый профиль, при передаче данных он задействован не будет.
Многих пользователей интересует вопрос, как узнать версию bluetooth. Сделать это можно несколькими способами, но самый простой – прочесть в спецификации устройства. Но куда важнее понимать, что скрывается за этими цифрами.
Как узнать версию Bluetooth: Видео
Технические данные различных протоколов
Это описание будет содержать далеко не самый полный перечень версий протоколов, а лишь наиболее значимые для всей технологии в целом. И начать, разумеется, стоит с самой первой, которая была создана без пары лет почти два десятилетия назад – в 1998 году, партнёрской группой SIG или Special Interested Group. Первичная же разработка была учреждена тогда ещё шведской фирмой Ericsson за 4 года до выхода на рынок. В результате успешного исследования был создан достойный аналог проводным технологиям и назвали его в честь датского короля северян-викингов Харальда Первого Синезубого.
Первая версия имела просто ошеломляющую совместимость между устройствами различных изготовителей. Скорость была крошечной, а радиус действия явно не соответствовал установленному стандарту. Если бы не оперативные попытки доработать технологию, вся задумка могла кануть в Лету. И профессиональные качества работников не подвели, ибо вскоре вышла сперва версия 1.1, а затем и 1.2, которая стала вершиной эволюции модулей первого поколения. Общую совместимость подтянули до достаточно высокого уровня, радиус действия задавался честными десятью метрами, скорость передачи сделали просто заоблачной – 721 Кбит/сек, разумеется, теоретически.
Версия 2.1
Второе поколение произвело революцию, но именно версия 2.1 стала той путеводной звездой, которая используется и поныне. Очень многие устройства начального и среднего класса используют именно эту вариацию bluetooth-модуля. Главный упор был сделан на скорость, а решением стала надстройка EDR. Именно благодаря ей стало возможным осуществлять передачу на скоростях, близких к 3 Мбит/с, а уровень энергопотребления был снижен в пять раз. Разумеется, появились различные профили и надстройки, вплоть до возможности осуществлять раздачу доступа к сети.
Третья версия
Высокоскоростная спецификация 3.0 имела много общего с Wi-Fi, но не имела с ней прямой совместимости, а использование SLI-технологии, по которой два bluetooth -модуля соединялись в одну систему, позволило увеличить скорость передачи до 24 Мбит/сек. Причём при перемещении больших файлов использовался более высокоскоростной, но и энергозатратный протокол, а для небольших файлов – весьма экономичный.
В основу четвёртого поколения устройств была положена идея доработать предыдущую технологию, чтобы энергопотребление стало минимальным, а все остальные функции и возможности были увеличены и расширены. Так, помимо скорости, был увеличен и радиус, который теперь мог доходить до сотни метров. Пакеты данных стали более оптимальными по размеру, а также было добавлено их 128-битное шифрование. Габариты передатчика стали просто крошечными, что даёт возможность использовать их повсеместно. Одним из основных моментов было добавление трёх режимов работы.
Здравствуйте.
3 декабря 2014 года Bluetooth SIG официально анонсировала спецификацию bluetooth версии 4.2.
В пресс-релизе указаны 3 главных нововведения:
- увеличение скорости приема-передачи данных;
- возможность подключения к интернету;
- улучшение конфиденциальности и безопасности.
В этой статье я хочу рассказать, как реализованы эти 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, публикуется:
- сервис: «IP Support Service» (IPSS) .
- профиль IPSP (Internet Protocol Support Profile) , который определяет поддержку передачи пакетов IPv6 между устройствами, имеющими BLE.
Профиль определяет следующие роли:
- роль маршрутизатора (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));
- обмен ключами.
- генерация краткосрочных ключей (Short Term Key (STK)) под названием «LE legacy pairing»
- генерация долговременных ключей (Long Term Key (LTK)) под названием «LE Secure Connections»
В связи с этим в криптографическом тулбоксе менеджера безопасности помимо 3-х существующих функций, появилось еще 5 и эти 5 используются только для обслуживания нового процесса сопряжения «LE Secure Connections». Эти функции генерируют:
- LTK и MacKey;
- подтверждающие переменные;
- переменные проверки аутентификации;
- 6-ти значные числа, используемые для отображения на связываемых устройствах.
Так вот, если при сопряжении во 2-й фазе по методу «LE legacy pairing» генерировалось 2 ключа:
- Temporary Key (TK): 128-ми битный временный ключ, используемый для генерации STK;
- Short Term Key (STK): 128-ми битный временный ключ, используемый для шифрования соединениЯ
- Long Term Key (LTK): 128-ми битный ключ, используемый для шифрования последующих соединениЙ.
- предотвращение отслеживания, т.к. теперь за счет «Numeric Comparison» есть возможность контролировать возможность подключения к Вашему устройству.
- улучшение энерго-эффективности, т.к. теперь не требуется дополнительная энергия для повторных генераций ключей при каждом соединении.
- отраслевой стандарт шифрования для обеспечения конфиденциальных данных.
4. Есть ли уже возможность пощупать?
Да, есть.
NORDIC Semiconductor выпустил «nRF51 IoT SDK» который включает в себя стек, библиотеки, примеры и API для устройств серии nRF51. Сюда входят:
- чипы nRF51822 и nRF51422;
- nRF51 DK;
- nRF51 Dongle;
- nRF51822 EK.
Обновлённый протокол для беспроводного обмена данными Bluetooth 4.1 должен выйти в свет уже в этом году. Новая версия «синего зуба» позволит напрямую взаимодействовать устройству с данным стандартом и облачному сервису. Если ныне действующая версия Bluetooth 4.0 имеет радиус действия, равный 30 м, не позволяя мобильным устройствам и ПК обмениваться файлами на превышающем данное значение расстоянии, то беспроводное соединение Bluetooth 4.1 сможет, задействовав в своих целях облачные возможности, существенно (хотя и косвенно) расширить лимит текущего диапазона.
В чём именно заключается преимущество данного нововведения? Учитывая растущую популярность фитнес-гаджетов и носимых устройств, оснастив своё устройство модулем с поддержкой Bluetooth 4.1, производитель сможет убрать в цепочке «гаджет — смартфон/планшет — доступ в облачный сервис» среднее звено и реализовать подключение напрямую, минуя дополнительные интерфейсы и т.д.
В принципе, с технической точки зрения реализовать подключение к облачной инфраструктуре можно уже сегодня, однако для этого необходимо задействовать различного рода сетевые устройства и так называемые хабы с полноценной операционной системой, роль которых может взять на себя мобильная электроника.
Планируется, что новая Bluetooth-сеть станет по-настоящему огромной инфраструктурой с абсолютно новым подходом во взаимодействии всевозможных типов портативной электроники и обычной техники. В конечном итоге это позволит реализовать обновлённый принцип удалённого мониторинга и управления. К примеру, данные непосредственно из носимого медицинского прибора смогут сразу попасть в облачную систему, а оттуда поступят на мобильное устройство вашего лечащего доктора. А пациенту, который является владельцем носимого гаджета, поддерживающего технологию Bluetooth 4.1, вовсе не нужно располагаться в непосредственной близости к врачу.
Модуль с Bluetooth 4.1 сможет взять на себя и роль хаба, принимая сигналы с других Bluetooth-устройств. Окончательные спецификации протокола Bluetooth 4.1 должны быть отработаны к концу этого года, а разработчики должны остановиться на двух ключевых направлениях: Low-Power-составляющая обновлённой технологии с ориентацией на популярные носимые устройства, а также полноценный Bluetooth 4.1 с функциями управления радиочастотами и ориентацией на применение модуля в персональных компьютерах и ноутбуках.
Здравствуйте.
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, публикуется:
- сервис: «IP Support Service» (IPSS) .
- профиль IPSP (Internet Protocol Support Profile) , который определяет поддержку передачи пакетов IPv6 между устройствами, имеющими BLE.
Главным требованием профиля для уровня 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»
В связи с этим в криптографическом тулбоксе менеджера безопасности помимо 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.
