Ядро системы — определение
В ядро системы (Core System) входит: 4 самых нижних уровня и ассоциированные с ними протоколы, определенные в спецификации Bluetooth, а так же один общий протокол сервисного уровня, называемый «протокол обнаружения сервисов» (service discovery protocol — SDP), полные требования к которому указаны в профиле общего доступа (generic access profile — GAP). Полноценное приложение Bluetooth требует целого ряда дополнительных сервисов и протоколов более высокого уровня, определенных в спецификации Bluetooth.
Контроллер Bluetooth
Три нижних уровня, группируемые иногда в подсистему, называются «контроллер Bluetooth«. Эта подсистема включает в себя стандартный интерфейс физической связи между самим контроллером Bluetooth и остальной частью системы, в которую входят L2CAP, сервисные уровни и самые верхние уровни (называемые Хост (Host) Bluetooth). Хоть этот интерфейс и не является обязательным, но архитектура Bluetooth изначально создавалась с учетом его существования с его определенными характеристиками. Спецификация Bluetooth обеспечивает взаимодействие между независимыми Bluetooth системами через определение сообщений протокола, с помощью которых осуществляется обмен между эквивалентными слоями, а также обеспечивает взаимодействие между независимыми Bluetooth подсистемами путем определения общего интерфейса между контроллерами и хостами Bluetooth.
На рисунке выше изображены функциональные блоки и линии, по которым взаимодействуют сервисы и перемещаются данные. Функциональные блоки, показанные на рисунке, являются информативными, в общем спецификация Bluetooth не определяет детали реализации, за исключением случаев, когда это требуется для совместимости.
Протоколы и управляющие сигналы ядра
Для всех внутренних операций, в процессе которых устройства Bluetooth обмениваются друг с другом, в соответствие со спецификацией Bluetooth, определены стандартные взаимодействия по сигнальным протоколам. Протоколы ядра системы:
— протокол радиосвязи (RF);
— протокол управления связью (Link Control — LC);
— протокол менеджера связи (Link Manager — LM);
— протокол L2CAP.
Все они полностью определены в соответствующих частях спецификации Bluetooth. Кроме того, для всех Bluetooth приложений обязателен протокол обнаружения сервисов (SDP), представляющий собой протокол сервисного уровня.
Ядро системы предлагает свои услуги через ряд точек доступа к ним (на рисунке они показаны в виде эллипсов). Эти услуги включают основные примитивы, управляющие ядром. Услуги можно разделить на три типа.
— услуги управления — изменяют поведение и режимы устройства;
— услуги управления транспортом — создают, изменяют и освобождают носителей траффика (каналы и связи);
— услуги передачи данных — используются для отправки данных, переносимых каналами и связями.
Первые две услуги принадлежат к командной плоскости (C-plane), а третья — принадлежит к пользовательской плоскости (U-plane).
Интерфейс хост-контроллер (HCI): разделение стека на «контроллер» и «хост»
Сервисный интерфейс к подсистеме контроллера Bluetooth определяется таким образом, чтобы контроллер Bluetooth мог рассматриваться в качестве стандартной части системы. В этой конфигурации контроллер Bluetooth работает на трех нижних уровнях, а уровень L2CAP находится вместе с другими приложениями Bluetooth в хост-системе. Этот стандартный интерфейс называется «Host to Controller Interface (HCI). Внедрение данного интерфейса является дополнительной услугой.
В связи с тем, что архитектурой Bluetooth определяется возможность различного взаимодействия между хостом и контроллером через HCI, существует ряд общих допущений. Контроллер Bluetooth предполагает ограниченные возможности буферизации данных в сравнении с хостом. Поэтому на уровень L2CAP возлагается некоторое простое управление ресурсами при передаче пакетов данных протокола (Protocol Data Unit — PDU) L2CAP в контроллер для транспортировки на другое устройство. Этот процесс включает в себя сегментацию сервисных пакетов данных (Service Data Unit — SDU) L2CAP на пакеты PDU, затем фрагментацию пакетов PDU на начальный и последующие пакеты, по размеру подходящие для буферов контроллера, и управление использованием буферов контроллера для обеспечения качества обслуживания (QoS) каналов.
Обнаружение ошибок на уровне L2CAP
Уровень Baseband поддерживает базовый протокол «автоматического повторения-запроса» («Automatic Repeat-reQuest» -ARQ) технологии Bluetooth. Уровень L2CAP может дополнительно обеспечивать обнаружение ошибок и ретрансляцию в пакеты PDU. Эта функция рекомендуется для приложения с требованиями к низкой вероятности необнаружения ошибок в пользовательских данных. Еще одна дополнительная функция L2CAP это «основанное на окне» управление потоком, которая может использоваться для управления выделением буфера в принимающем устройстве. Обе эти дополнительные функции увеличивают производительность QoS в определенных сценариях.
Эти свойства могут быть необязательными для встраиваемых реализациях Bluetooth, объединяющие все уровни в единую систему.
Интерфейсы тестирования: радиоканал и интерфейс управления тестами (Test Control Interface -TCI)
Спецификация ядра системы требует автоматизированное тестирование, соответствующее реализации Bluetooth. Это достигается путем разрешения тестеру контролировать реализацию Bluetooth через интерфейс радиоканала, который является общим для всех Bluetooth систем, а также через интерфейс управления тестами (TCI), который необходим только для тестирования соответствия системы спецификации.
Для обеспечения правильных ответов на запросы от удаленных устройств тестер использует так называемые «включения в тесты» (implementation under test — IUT), обмениваясь ими через интерфейс радиоканала. Тестер управляет включениями через TCI.
Для тестирования каждого архитектурного уровня и протокола TCI использует различный набор команд (Service Interface). В рамках подсистемы контроллера Bluetooth существует специальное подмножество команд интерфейса TCI для тестирования HCI, которые проверяют каждый слой и протокол. Для тестирования уровня и протокола L2CAP используется отдельный сервисный интерфейс. Этот интерфейс не определен в спецификации Bluetooth, он определяется отдельно в спецификации TCI. Реализация сервисного интерфейса для L2CAP требуется только для тестирования L2CAP на его соответствие спецификации.
Архитектурные блоки ядра
Менеджер канала
Менеджер канала отвечает за создание, управление и уничтожение каналов L2CAP, предназначенных для транспортировки сервисных протоколов и потоков данных приложений. Для взаимодействия с таким же менеджером на другом устройстве менеджер канала использует протокол L2CAP, создавая каналы и соединяя свои конечные точки с соответствующими точками другого. Для создания новой логической связи (при необходимости) менеджер канала взаимодействует со своим менеджером связи и настраивает эти связи для поддержки качества обслуживания в соответствии с передаваемыми данными.
Менеджер ресурсов L2CAP
Блок менеджера ресурсов L2CAP отвечает за управление порядком предоставления фрагментов PDU в Baseband и за некоторое планирование передачи между каналами, для предотвращения лишения доступа каналов L2CAP к физическому каналу связи Bluetooth, а так же для предотвращения истощения ресурсов контроллера. Необходимость в этом обусловлена тем, что архитектурная модель не предполагает безграничную буферизацию контроллера Bluetooth и тем, что HCI не представляет собой канал с бесконечной полосой пропускания.
Менеджеры ресурсов L2CAP также могут осуществлять надзор над трафиком для того, что бы обеспечить приложениям, предоставляющим SDU для L2CAP, качество обслуживания, соответствующее настройкам QoS. Общая модель передачи данных Bluetooth предполагает что приложения «дружелюбны» к технологии, и не определяет, что в обратном случае реализация справится с возникшей проблемой.
Менеджер устройства
Менеджер устройства является функциональным блоком в Baseband, который управляет общим поведением Bluetooth устройства. Он отвечает за все операции в системе Bluetooth, которые не связаны непосредственно с транспортировкой данных, а именно: за обнаружение поблизости других устройств Bluetooth, подключение к другим устройствам и за возможность этого устройства обнаруживаться или подключаться.
Для выполнения своих функций менеджер устройства запрашивает доступ к транспортной среде от контроллера ресурсов Baseband.
Менеджер устройства также контролирует поведение локального устройства и включает ряд команд HCI, таких, как управление названием устройства, управление ключами связей и управление другим функционалом.
Менеджер связи
Менеджер связи отвечает за создание, изменение и освобождение логических связей (и, если необходимо, ассоциированными с ними транспортами), а также за обновление параметров, соответствующих физическим связям между устройствами. Это достигается путем общения с таким же менеджером на другом устройстве при помощи протокола менеджера связи (LMP).
LMP позволяет, по необходимости, создавать новые логические связи и логические транспорты между устройствами, а также осуществлять общий контроль над связью и транспортными атрибутами, такими как обеспечение шифрования логического транспорта, адаптацией мощности передачи физической связи или корректировку параметров QoS для логической связи.
Менеджер ресурсов Baseband
Менеджер ресурсов Baseband отвечает за весь доступ к радио. Он имеет две основные функции. По своей сути это планировщик, предоставляющий время на доступ к физическим каналам для всех сущностей, нуждающимся в доступе к каналу. Другой основной функцией является распределение доступа этих сущностей к каналу. Разрешение на доступ фактически является обязательством по предоставлению определенного QoS, которое необходимо для того, чтобы пользовательское приложение выполнялось с ожидаемым результатом.
Разрешение на доступ и функции планирования должны учитывать любое поведение, требующее использования радио, например, нормальный обмен данными между подключенными устройствами через логические связи и логические транспорты, а также использование радио для поиска, установки соединения, возможности обнаружения или подключения, или для чтения показаний при использовании режима адаптивной перестройки частоты (AFH).
В некоторых случаях результатом планирования логической связи становится переход к ранее используемого к другому физическому каналу. Это может происходить, например, когда устройство становится участником сети scatternet, или при периодическом обнаружении находящихся рядом устройств или сканировании запросов на соединение. Когда физические каналы не выровнены по временному слоту, менеджер ресурсов реорганизует время между слотами в текущем и новом физических каналах. В некоторых случаях слоты будут выровнены через определенный временной интервал сами по себе при использовании одних и тех же часов обоими физическими каналами.
Контроллер связи
Контроллер связи отвечает за кодирование и декодирование пакетов полезных данных и параметров, связанных с физическим каналом, логическим транспортом и логической связью.
Контроллер связи переносит сигнальные данные протокола управления связью (в тесном сотрудничестве с функцией планирования менеджера ресурсов), которые используются для передачи сигналов управления потоком и сигналов запросов на признание и ретрансляцию.
Радио
Блок радио предназначен для передачи и приема пакетов информации по физическому каналу. Блок Baseband управляет блоком радио и контролирует временные промежутки и несущие частоты блока радио. Блок радио преобразует поток данных в (из) Baseband и физического канала в необходимые форматы.