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

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

    Similar posts

    Comments 16

      0
      А в чём проблема обновить существующие чипы? Ведь просто изменился протокол передачи, а не физическая составляющая. Или микропрограмма в самом чипе зашита?
        +1
        Как правило, bluetooth стек зашит в отдельной микросхеме, либо чипсете. «во внешний мир» смотрит интерфейс более высокого уровня.
          0
           ну, у TI их CC2541 вроде как умеет таки по воздуху обновляться (то есть bluetooth стек можно обновить. в теории). Другое дело насколько этот чип и эти возможности задействованы в конечных устройствах, ну и будет ли вообще Bluetooth 4.2 для этого самого CC2541.
          0
          Если L2CAP находится на уровне микрокода, то не прошить, а если на уровне firmware то можно. Например некоторые чипы от TI или чипы Нордика, там стек полностью программный. Однако надо помнить, что мы говорим о BLE, т.е. об экономии, а значит, что в других чипах просто может не быть аппаратных ресурсов, например памяти для буферов.
          0
          Тут вопрос возник, любой ли Bluetooth версии 4.0 и выше является энергоэффективным или только с приставкой LE?
          Т.е. если в характеристиках телефона указана поддержка bluetooth 4.0 (или выше), но ничего не сказано про LE, то при сопряжении с носимой электроникой, поддерживающей bluetooth LE, будет ли меньше сажаться батарея?
            0
            BLE это отдельная штука, не совместимая с «обычным» Bluetooth, там в общем то и не поддерживаются обычные Bluetooth профили и так далее. Писать приложение под BLE нужно отдельно и иначе, железяку делать соответственно тоже.

            То есть BLE это не опция для экономии энергии, это отдельная технология передачи данных сильно отличающаяся от традиционного Bluetooth.
              0
              В целом понятно, что это разные вещи. Но всё же можно их совместить в одном чипе? Если да, то с 4 версии во всех чипах есть поддержка BLE или нет?
              Всё же носимая электроника набирает обороты, но её плюсы особенно проявляются при постоянном контакте со смартфоном.
                0
                Большая часть чипов умеют и то и это. Более того, многие чипы умеют одновременно работать и с ble устройствами и с bluetooth (например в iPhone стоит такой — он может и с гарнитурой работать и одновременно с ble устройством). Но понятно что одно и то же соединение одновременно не может быть и ble и обычным.

                Чтобы была понятна область применимости ble: типичная пиковая пропускная способность у ble в реальной жизни порядка 1 килобайта в секунду (8 кбит). Например для гарнитуры, для передачи голоса во вменяемом качестве, этого уже не хватит.
                  0
                  Понятно, спасибо.
                  Т.е. если в спецификации указана одна из последних версий bluetooth, то это вовсе не гарантирует наличие BLE.
                    0
                    Это не гарантирует, что устройство будет именно по BLE общаться с вашим смартфоном.

                    Вот тут есть списочек оборудование которое точно работает через BLE: www.bluetooth.com/Pages/Bluetooth-Smart-Devices-List.aspx

                    А вот тут описание что же это за значки такие загадочные «Bluetooth smart» и «Bluetooth smart ready»: www.bluetooth.com/Pages/Bluetooth-Brand.aspx

                    Собственно вот на эти значки, по хорошему, и нужно смотреть при покупке дивайсины.
                      0
                      Благодарю. Вот теперь понятно куда смотреть — на значки :)
                      Smart Ready для «центральных» устройств, smart — для портативных гаджетов. При этом Smart Ready и с обычными устройствами общается.
                      +1
                      Если в спецификации на устройство указано Bluetooth 4, значит устройство поддерживает полный стандарт, а вот если у стройство поддерживает только BLE, то так и пишут.
                      Есть ещё устоявшиеся названия:
                      — smart ready — полная поддержка
                      — smart — только BLE.

                      Еще есть названия:
                      — dual mode. — полная поддержка
                      — single mode — BLE
                        +1
                        Ну, вообще с этим Bluetooth 4 полная путаница. Ну например в спеках на смартфоны с Win 8 давным давно светится что оно держит Bluetooth 4.0, при этом они естественно никакого BLE не умеют (просто потому, что винда мобильная научилась с BLE работать только с версии 8.1). С андроидами долгое время была та же песня (то есть чип унутре то может и умел что-то с BLE, но вот операционка ничего не могла, и соответственно пользователю, равно как и разработчику, ничего доступно не было).
                          0
                          Согласен с вами. Тут уже подход производителей ОС, что они разрешат, то и будет.
                          Вот Вам еще пример: Apple. API для BLE появилось только в iOS5 и для телефонов, начиная с 4S. Почему Apple не давало API для более ранних версий ОС? Почему сейчас API только для BLE? Потому, что так хочет Apple. А если Вы все-таки хотите разрабатывать приложения для iOS, используя обычный bluetooth, будьте добры, зарегистрируйтесь в программе MFi (mobile for i...), заплатите взнос ~10000$ и платите роялити с каждой продажи.
                          Или, например, тот же андроид. Почему используя обычный bluetooth, у разработчика есть возможность использовать только RFCOMM? Правильно, так решил Google.

                          Но в случае в Apple, можно поставить альтернативный стек и иметь все возможности BT4, а в случае с андроидом: рут и мощный bluez у вас в руках.
              0
              «должны появиться первые чипы, поддерживающие версию 4.2»
              Я так понимаю, что тому же нордику достаточно выкатить новый стек для имеющихся 51822, обозвать его, например, S140, и просто заменить в примерах линкование S110 на 140. Тексасу будет сложнее, они блютопию на корню выкупили, а программистов не выкупили, и опять рукожопые индусы наговнокодят для 2541 :(
                0
                Да, Вы правы, нордик уже это сделал.
                В «nRF51 IoT SDK», о котором я писал, имеется новая прошивка SoftDevice, под многозначительным названием
                «s1xx-iot-prototype2_softdevice.hex».Ну а реализация IPv6 — это уровень SDK, находящаяся в этом же SDK.

              Only users with full accounts can post comments. Log in, please.