Стек протокола Bluetooth

Bluetooth® Special Interest Group (SIG) [1] и [2] задает стек протокола для Bluetooth низкой энергии (BLE) и технологии базовой скорости / улучшенной скорости передачи данных (BR/EDR) Bluetooth. Основные цели этих технических требований состоят в том, чтобы разработать интерактивные сервисы и приложения по совместимым радио-компонентам и протоколы передачи данных.

Этот рисунок показывает архитектуру Bluetooth-стека.

Bluetooth-устройства могут быть одним из этих двух типов:

  • Один режим – Поддержки BR/EDR или профиль LE

  • Двойной режим – Поддержки BR/EDR и профили LE

Последующие разделы предоставляют подробную информацию об архитектуре Стека Протокола BLE и Bluetooth Стек Протокола BR/EDR.

Стек протокола BLE

Этот рисунок сравнивает стек протокола BLE с образцом модели Взаимодействия открытых систем (OSI).

В предыдущей фигуре стек протокола BLE показывают наряду с образцом модели OSI.

  • Существует взаимно-однозначное отображение на физическом уровне (PHY)

  • Слой канала передачи данных (DLL) OSI сопоставляет с протоколом (L2CAP) управления и адаптации логической ссылки BLE и слоем ссылки (LL)

  • В стеке BLE более высокие слои предоставляют услуги прикладного уровня, роли устройства и режимы, управление связью и протокол системы защиты

Функциональность стека протокола BLE разделена между тремя основными слоями: Контроллер, Хост, и Профили приложений и Сервисы.

Контроллер

Слой контроллера включает BLE PHY, LL и интерфейс хост-контроллера (HCI) стороны контроллера.

BLE PHY.  Воздушный интерфейс BLE PHY действует в том же нелицензированном Промышленнике на 2,4 ГГц, Научном, и Медицинском (ISM) диапазон частот как Wi-Fi®. Воздушный интерфейс BLE PHY также включает эти характеристики:

  • Операционная радиочастота (RF) находится в области значений от 2,4000 ГГц до 2,4835 ГГц, включительно.

  • Пропускная способность канала составляет 2 МГц. Операционная полоса разделена на 40 каналов, k = 0, …, 39. Центральная частота k th канал 2402 + k × 2 МГц.

    • Пользовательские пакеты данных передаются с помощью каналов в области значений [0, 36].

    • Рекламные пакеты данных передаются в каналах 37, 38, и 39.

  • Схема модуляции гауссова shift-keying частоты (GFSK) реализована.

  • БЛ ФИ использует скачкообразно перемещающий частоту спектр распространения (FHSS), чтобы уменьшать интерференцию и противостоять удару исчезающих каналов. Время между транзитными участками частоты может варьироваться от 7,5 мс до 4 с и установлено во время соединения для каждого ведомого устройства.

  • Поддержка пропускной способности на уровне 1 Мбит/с обязательна для версии 4.x спецификации совместимые устройства. На скорости передачи данных 1 Мбит/с не закодирована передача.

  • Опционально, устройства, совместимые с версией 5.1 Спецификации Ядра Bluetooth, поддерживают эти дополнительные скорости передачи данных:

    • Закодированная передача при битрейтах 500 Кбит/с или 125 Кбит/с

    • Незакодированная передача на небольшом уровне 2 Мбит/с

LL.  LL выполняет задачи, похожие на слой среднего управления доступом (MAC) модели OSI. В Bluetooth LL взаимодействует через интерфейс непосредственно с BLE PHY и управляет состоянием ссылки радио, чтобы задать роль устройства как ведущее устройство, ведомое устройство, рекламодатель, или, сканер.

HCI стороны контроллера.  HCI на стороне контроллера обрабатывает интерфейс между хостом и контроллером. HCI задает набор команд и событий для передачи и приема пакетных данных. При получении пакетов от диспетчера HCI извлекает необработанные данные в контроллере, чтобы отправить к хосту.

Хост

Хост включает HCI стороны хоста, L2CAP, протокол атрибута (ATT), типовой профиль атрибута (GATT), протокол менеджера безопасности (SMP) и типовой профиль доступа (GAP).

HCI стороны хоста.  HCI на стороне хоста обрабатывает интерфейс между хостом и контроллером. HCI задает набор команд и событий для передачи и приема пакетных данных. При передаче данных HCI переводит необработанные данные в пакеты, чтобы отправить их с хоста на контроллер.

L2CAP.  L2CAP инкапсулирует данные из BLE более высокие слои в стандартный формат пакета BLE для передачи или извлекает данные из стандартного пакета BLE LL на приеме) согласно настройке ссылки, заданной на слоях ATT и SMP.

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

Атрибуты устройств представлены как:

  • Указатель атрибута является 16-битным значением идентификатора, присвоенным сервером позволять клиенту сослаться на те атрибуты.

  • Тип атрибута является универсально уникальным идентификатором (UUID), заданный SIG Bluetooth. Например, UUID 0x2A37 представляет измерение сердечного ритма.

  • Значение атрибута является полем переменной длины. UUID, сопоставленные с и сервисный класс служебной книжки, содержащей значение атрибута, определите длину поля значения атрибута.

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

GATT  GATT служит ссылочной основой для всех основанных на GATT профилей. GATT инкапсулирует ATT и ответственен за координирование обмена профилями в ссылке BLE. Профили включают информацию и данные, такие как присвоение указателя, UUID и набор полномочий.

Для устройств, которые реализуют профиль GATT,

  • client является устройством, которое инициирует команды и запросы к серверу. Клиент может получить ответы, признаки и уведомления.

  • server является устройством, которое принимает входящие команды и запрашивает от клиента. Сервер отправляет ответы, признаки и уведомления клиенту.

GATT использует клиент-серверную архитектуру. Роли не фиксируются и определяются, когда устройство инициирует заданную процедуру. Роли выпущены, когда процедура заканчивается.

Терминология, используемая в GATT, включает:

  • Service — Набор данных и сопоставленных поведений раньше выполнял конкретную функцию или функцию

  • Characteristic — Значение используется в сервисе наряду с соответствующими полномочиями

  • Characteristic descriptor — Описание связанного характеристического поведения

  • GATT-Client — Клиент GATT инициирует команды и запросы к серверу и может получить ответы, признаки и уведомления, отправленные сервером

  • GATT-Server — Сервер GATT принимает входящие команды и запрашивает от клиента и отправляет ответы, признаки и уведомления клиенту

SMP.  SMP применяет алгоритмы безопасности, чтобы зашифровать и дешифровать пакеты данных. Этот слой задает инициатора и респондента, соответствуя ведущему устройству и ведомому устройству, когда-то связь устанавливается.

GAP.  GAP задает роли, режимы и процедуры устройства. Это также справляется с установлением связи и безопасностью. GAP взаимодействует через интерфейс непосредственно со слоем Application Profiles и Services (App).

Слой APP

Слой App является прямыми профилями определения пользовательского интерфейса, которые предоставляют функциональную совместимость между различными приложениями. Спецификация ядра Bluetooth позволяет поставщикам задать собственные профили для вариантов использования, не заданных профилями SIG.

Примечание

Для получения дополнительной информации об архитектуре стека протоколов BLE, смотрите, что объем 3, Часть C, разделяет 2 и 2.1 из Спецификации [1] Ядра Bluetooth.

Bluetooth Стек Протокола BR/EDR

Этот рисунок сравнивает блок-схему стека протокола BR/EDR Bluetooth и с образцом модели OSI.

Отображение стека BR/EDR к образцу модели OSI как показано ниже:

  • Слои BR/EDR Radio и Baseband и Link Control стека Bluetooth BR/EDR сопоставляют со слоем OSI PHY.

  • Менеджер по ссылке протокол (LMP), L2CAP, Заменяющий Протокол Кабеля (RFCOMM) и слои PPP стека Bluetooth BR/EDR сопоставляют со слоем канала передачи данных OSI.

  • Пользовательский дейтаграммный протокол (UDP), протокол управления передачей (TCP) и слои интернет-протокола (IP) стека Bluetooth BR/EDR сопоставляют с объединенные, сетевые, транспортные и сеансовые уровни образца модели OSI.

  • Существует взаимно-однозначное отображение на прикладном уровне.

Протоколы ядра

Протоколы ядра Bluetooth и радио Bluetooth требуются большинством bluetooth-устройств. Протоколы ядра включают эти слои.

Радио BR/EDR.  Радио BR/EDR является самым низким заданным слоем спецификации Bluetooth. Режим BR обязателен, тогда как режим EDR является дополнительным. Этот слой задает требования устройства приемопередатчика Bluetooth, действующего в диапазоне частот ISM на 2,4 ГГц. Это реализует 1600 транзитные участки/секунда метод FHSS. Радио скачкообразно двигается псевдослучайным способом на 79 обозначенных каналах Bluetooth. Каждый канал Bluetooth имеет пропускную способность 1 МГц. Каждая частота расположена в (2402 + k) МГц, где k = 0,1... 78. Метод модуляции для режима BR и EDR является GFSK и дифференциальным манипулированием сдвига фазы (DPSK), соответственно. Скорость в бодах является 1 Msymbols/s. Радио BR/EDR Bluetooth использует топологию дуплекса деления времени (TDD), в которой передача данных происходит в одном направлении одновременно. Передача чередуется в двух направлениях, один за другим.

Основная полоса и Управление Ссылкой.  Слой управления основной полосой и ссылкой включает ссылку РФ PHY между различными bluetooth-устройствами, формируя piconet. Основная полоса обрабатывает обработку канала и синхронизацию, и управление ссылкой обрабатывает управление доступом к каналу. Этот слой обеспечивает эти два различных типов ссылок РФ PHY с их соответствующими основополосными пакетами:

  • Синхронный с установлением соединения (SCO) – Поддержки аудиотрафик в реальном времени

  • Асинхронный с установлением соединения (ACL) – пакетная передача данных о Поддержках

Менеджер по ссылке протокол (LMP).  Слой LMP, в основном, ответственен за настройку ссылки и настройку ссылки между различными bluetooth-устройствами. Эти процессы включают функции защиты установления, такие как аутентификация и шифрование путем генерации, обмениваясь и проверяя ссылку и ключи шифрования. Кроме того, этот слой управляет режимами степени и рабочими циклами устройства радио Bluetooth и состояниями связи модуля Bluetooth в piconet.

L2CAP.  L2CAP адаптирует протоколы более высокого слоя по основной полосе. Это экранирует протоколы более высокого слоя от деталей протоколов нижнего уровня. L2CAP предоставляет услуги без установления соединения и с установлением соединения протоколам более высокого слоя. Это включает протокол, мультиплексирующий возможность, сегментацию и операции повторной сборки и абстракции группы.

SDP.  Услуги по открытию являются важным аспектом среды Bluetooth. Сервисный протокол открытия (SDP) обеспечивает средние значения для приложений, чтобы запросить сервисы и характеристики сервисов, после которых связь может быть установлена между двумя или больше bluetooth-устройствами. SDP очень отличается от сервисного открытия в традиционных основанных на сети средах. SDP создается сверху L2CAP.

Заменяющий протокол кабеля

Заменяющий протокол кабеля в стеке Bluetooth BR/EDR использует RFCOMM, чтобы обеспечить эмуляцию последовательных портов по L2CAP. RFCOMM эмулирует управление RS-232 и сигналы данных по основной полосе Bluetooth и предусматривает транспортные возможности для сервисов более высокого слоя, которые используют последовательный интерфейс в качестве транспортного механизма. RFCOMM также обеспечивает несколько одновременных связей с одним устройством и включает связи с несколькими устройствами.

Протоколы управления телефонией

Спецификация протокола управления телефонией, двоичный файл (двоичный файл TCS), задает управление соединением, сигнализирующее, чтобы установить данные и голосовые вызовы между bluetooth-устройствами. Это создается сверху L2CAP. Кроме того, двоичный файл TCS задает процедуры управления мобильности по обработке bluetooth-устройств.

Принятые протоколы

В дополнение к протоколам ядра стек Bluetooth BR/EDR включает протоколы, принятые от других стандартных тел. Эти принятые протоколы заданы в технических требованиях, выпущенных другими делающими стандарт организациями, и включены в среду Bluetooth.

PPP.  Протоколом "точка-точка" (PPP) является Инженерная группа по развитию интернета (IETF) [3] стандартный протокол для переноса дейтаграмм IP по магистральной линии. PPP работает на основе RFCOMM, чтобы понять двухточечные соединения.

TCP, UDP и IP.  Эти слои являются IETF-заданными протоколами основы набора протоколов TCP/IP.

  • TCP – Этот протокол обеспечивает надежную виртуальную связь между устройствами, чтобы понять передачу данных. TCP обрабатывает данные как поток байтов и передает их без любых ошибок или дублирования.

  • UDP – Этот протокол является альтернативой TCP и обеспечивает ненадежную дейтаграммную связь между устройствами. Как нет никакой сквозной связи в UDP, данные являются переданной ссылкой ссылкой без любой гарантии сервиса.

  • IP – Этот слой является протоколом слоя сети, который включает дейтаграммный сервис между устройствами, поддерживая и TCP и UDP.

Использование TCP, UDP и IP в стеке Bluetooth BR/EDR включает связь с любым другим устройством, соединенным к Интернету.

OBEX.  Объектный обмен (OBEX) протокол является протоколом сеансового уровня, разработанным Инфракрасной Ассоциацией Данных (IrDA), чтобы обмениваться объектами. Протокол OBEX обеспечивает функциональность, похожую на тот из HTTP, но более простым способом. HTTP является протоколом прикладного уровня и разделенный на уровни выше TCP/IP. Протокол OBEX предоставляет клиенту надежный транспорт для соединения с сервером. Это также предоставляет модель для представления объектов и операций.

WAE и WAP.  Стек Bluetooth BR/EDR включает среду приложений беспроводной связи (WAE) и протокол приложения беспроводной связи (WAP) в его архитектуру. Преимущества использования функций WAE/WAP в Bluetooth-стеке:

  • Создайте шлюзы приложений, которые действуют как интерфейс между серверами WAP и некоторым другим приложением на PC

  • Обеспечьте функции, такие как дистанционное управление и выборка данных с PC на телефон Bluetooth

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

Профили приложений и сервисы

Для получения дополнительной информации отошлите Слой APP.

Альтернативный MAC/PHY

Альтернативный MAC/PHY (AMP) менеджер является вторичным контроллером в системе ядра Bluetooth. После того, как связь L2CAP устанавливается между двумя устройствами по радио BR/EDR, менеджер по AMP может обнаружить УСИЛИТЕЛИ, которые доступны на другом устройстве. Если AMP распространен между двумя устройствами, система ядра Bluetooth обеспечивает механизмы для движущегося потока данных от диспетчера BR/EDR контроллеру AMP.

Каждый менеджер по AMP состоит из уровня адаптации протокола (PAL) сверху MAC и PHY. PAL сопоставляет протоколы Bluetooth с определенными протоколами базового MAC и PHY.

Каналы L2CAP могут быть созданы на или перемещены в, AMP. Если AMP, физическая ссылка имеет тайм-аут контроля ссылкой, то каналы L2CAP могут попятиться к радио BR/EDR. Чтобы минимизировать потребление энергии в устройстве, УСИЛИТЕЛИ включены или отключены как требуется.

HCI

HCI обеспечивает интерфейс команды к радио BR/EDR, основополосному диспетчеру и менеджеру по ссылке. Это - один стандартный интерфейс для доступа к основополосным возможностям Bluetooth, состоянию оборудования и регистрам управления.

Примечание

Для получения дополнительной информации об архитектуре стека протоколов BR/EDR Bluetooth, смотрите, что объем 1, Часть A, разделяет 2 и 2.1 из Спецификации [1] Ядра Bluetooth.

Ссылки

[1] Специальная группа (SIG) Bluetooth. "Спецификация Ядра Bluetooth". Версия 5.1. https://www.bluetooth.com/.

[2] Технологический Веб-сайт Bluetooth. “Технологический Веб-сайт Bluetooth | официальный сайт Технологии Bluetooth”. Полученный доступ 6 ноября 2019. https://www.bluetooth.com/.

[3] IETF. “Интернет-Стандарты”. Полученный доступ 6 ноября 2019. https://www.ietf.org/.

[4] “Стек Протокола Bluetooth - Обзор | Темы ScienceDirect”. Полученный доступ 15 ноября 2019. https://www.sciencedirect.com/.

Похожие темы

Для просмотра документации необходимо авторизоваться на сайте