Нижние уровни

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

Выше радио-уровня основная полоса и уровень контроллера ссылки. Спецификация Bluetooth не устанавливает ясное различие между ответственностью основной полосы и тех из контроллера ссылки. Лучший способ думать об этом состоит в том, что основополосная часть уровня ответственна за то, что должным образом отформатировала данные для передачи к и от радио-уровня. Кроме того, это обрабатывает синхронизацию ссылок. Часть контроллера ссылки этого уровня ответственна за выполнение команд менеджера по ссылке и установление и поддержание ссылки, предусмотренной менеджером по ссылке.

Менеджер по ссылке самостоятельно переводит команды интерфейса хост-контроллера (HCI), которые это получает в операции основополосного уровня. Это ответственно за установление и конфигурирование ссылок и управление запросами на изменение питания среди других задач.

Вы заметили, что ссылки упомянули многочисленные времена в предыдущих абзацах. Спецификация Bluetooth определяет два типа ссылок между bluetooth-устройствами:

• Синхронный, С установлением соединения (SCO), для использования изохронной и голосовой связи, например, гарнитур

• Асинхронный, Без установления соединения (ACL), для передачи данных, такой как обмен vCards

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

Ссылка ACL существует между ведущим устройством и ведомым устройством момент, соединение установлено. Пакеты данных использование Bluetooth для ACL соединяет всех, имеют 142 бита кодирования информации в дополнение к полезной нагрузке, которая может быть столь же большой как 2 712 битов. Дополнительное кодирование объема данных усиливает защиту при передаче. Это также помогает поддержать устойчивый коммуникационный канал в среде, заполненной другими устройствами и общим шумом.

HCI (интерфейс хост-контроллера) уровень действует как граница между нижними уровнями стека протоколов Bluetooth и верхних уровней. Спецификация Bluetooth определяет стандартный HCI для поддержки систем Bluetooth, реализованных через два отдельных процессора. Например, система Bluetooth на компьютере могла бы использовать процессор модуля Bluetooth, чтобы реализовать нижние уровни штабеля (радио, основная полоса, контроллер ссылки, и соединить менеджера). Это могло бы тогда использовать свой собственный процессор для реализации верхних уровней (L2CAP, RFCOMM, OBEX и выбранные профили). В этой схеме более низкая часть известна как модуль Bluetooth и верхняя часть как узел Bluetooth.

Конечно, это не требуется, чтобы делить штабель Bluetooth таким образом. Гарнитуры Bluetooth, например, комбинируют модуль и части, относящиеся к хосту штабеля на одном процессоре, потому что они должны быть маленькими и автономными. В таких устройствах HCI не может быть реализован вообще, если не требуется тестирование устройства.

Поскольку Bluetooth, HCI четко определен, можно записать драйверы, обрабатывающие различные модули Bluetooth от различных производителей. Apple обеспечивает объект контроллера HCI, поддерживающий реализацию USB уровня HCI.

Верхние уровни

Выше HCI уровень верхние уровни стека протоколов. Первым из них является L2CAP (протокол управления логическим каналом и протокол адаптации) уровень. L2CAP прежде всего ответственен за:

• Установление соединений через существующий ACL соединяются или запрос ссылки ACL, если Вы уже не существуете

• Мультиплексируя между различными протоколами верхнего уровня, такими как RFCOMM и SDP, чтобы позволить многим различным приложениям использовать единственную ссылку ACL

• При переупаковке пакетов данных это получает от более высоких уровней в форму, ожидаемую нижними уровнями

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

Выше уровня L2CAP вполне так линейно не упорядочиваются оставшиеся слои стека протоколов Bluetooth. Однако это целесообразно обсуждать протокол обнаружения службы затем, потому что это существует независимо от других уровней протокола более высокого уровня. Кроме того, это характерно для каждого bluetooth-устройства.

SDP (протокол обнаружения службы) определяет действия и для серверов и для клиентов служб Bluetooth. Спецификация определяет службу как любую функцию, которая применима другим (удаленным) bluetooth-устройством. Единственное bluetooth-устройство может быть и сервером и клиентом служб. Примером этого является сам компьютер Macintosh. Используя профиль передачи файлов (описанный в профилях Bluetooth — Иерархия Групп) компьютер Macintosh может просмотреть файлы на другом устройстве и позволить другим устройствам просматривать его файлы.

Клиент SDP связывается с сервером SDP с помощью зарезервированного канала на ссылке L2CAP для обнаружения, какие службы доступны. Когда клиент находит желаемую службу, она запрашивает отдельное соединение использовать службу. Зарезервированный канал выделен коммуникации SDP так, чтобы устройство всегда знало, как соединиться со службой SDP на любое другое устройство. Сервер SDP поддерживает свою собственную базу данных SDP, которая является рядом служебных книжек, описывающих службы предложения сервера. Вместе с информацией, описывающей, как клиент может соединиться со службой, служебная книжка содержит UUID службы или универсально уникальный идентификатор.

Также выше уровня L2CAP на рисунке 1-1 уровень RFCOMM. Протокол RFCOMM эмулирует настройки строки последовательного кабеля и состояние последовательного порта RS-232. RFCOMM соединяется с нижними уровнями стека протоколов Bluetooth через уровень L2CAP.

Путем обеспечения эмуляции последовательного порта RFCOMM поддерживает устаревшие приложения последовательного порта. Это также поддерживает протокол OBEX (обсудил затем), и несколько из профилей Bluetooth (обсужденный в профилях Bluetooth — Иерархия Групп).

OBEX (объектный обмен) является протоколом передачи, определяющим объекты данных и протокол связи, который два устройства могут использовать для простого обмена теми объектами. Bluetooth принял OBEX от спецификации IrDA IrOBEX, потому что нижние уровни протокола IrOBEX очень подобны нижним уровням стека протоколов Bluetooth. Кроме того, протокол IrOBEX уже общепризнан и поэтому хороший выбор для Bluetooth SIG, стремящийся способствовать принятию при помощи существующих технологий.

Bluetooth-устройство, желающее устанавливать сеанс связи OBEX с другим устройством, считается клиентским устройством.

1. Клиент сначала отправляет запросы SDP, чтобы удостовериться, что другое устройство может действовать как сервер служб OBEX.

2. Если серверное устройство может предоставить услуги OBEX, оно отвечает своей служебной книжкой OBEX. Эта запись содержит номер канала RFCOMM, который клиент должен использовать для установления канала RFCOMM.

3. Дальнейшая коммуникация между этими двумя устройствами передается в пакетах, содержащих запросы и ответы и данные. Формат пакета определяется сеансовым протоколом OBEX.

Несмотря на то, что OBEX может поддерживаться по TCP/IP, этот документ не обсуждает эту опцию (и при этом это не описано в спецификации Bluetooth).

Основной профиль

В основе профиля иерархия является типовым профилем доступа (GAP), определяющим непротиворечивые средние значения для установления основополосной ссылки между bluetooth-устройствами. В дополнение к этому GAP определяет:

• Какие опции должны быть реализованы во всех bluetooth-устройствах

• Универсальные процедуры для обнаружения и соединения с устройствами

• Основная терминология пользовательского интерфейса

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

Оставление профилями

Профиль приложений открытия службы описывает, как приложение должно использовать SDP (описанный в Стеке протоколов Bluetooth) для обнаружения служб на удаленное устройство. Как требуется GAP, любое bluetooth-устройство должно быть в состоянии соединиться с любым другим bluetooth-устройством. На основе этого профиль приложений открытия службы требует, чтобы любое приложение было в состоянии узнать, какие службы доступны на любом bluetooth-устройстве, с которым это соединяется.

Профиль устройства интерфейса пользователя (HID) описывает, как связаться с устройством класса HID с помощью ссылки Bluetooth. Это описывает, как использовать USB протокол HID для обнаружения набора функций устройства класса HID и как bluetooth-устройство может поддерживать службы HID с помощью уровня L2CAP. Для получения дополнительной информации о USB протокол HID, посмотрите http://www .usb.org.

Как его имя предполагает, профиль последовательного порта определяет эмуляцию последовательного кабеля RS-232 для bluetooth-устройств. Также, профиль позволяет унаследованным приложениям использовать Bluetooth, как будто это была ссылка последовательного порта, не требуя никакой модификации. Профиль последовательного порта использует протокол RFCOMM для обеспечения эмуляции последовательного порта.

Профиль коммутируемых сетей (DUN) основан на профиле последовательного порта и описывает, как устройство терминала, такое как портативный компьютер, может использовать устройство шлюза, такое как мобильный телефон или модем, для доступа к основанной на телефоне сети. Как другие профили, созданные поверх профиля последовательного порта, виртуальный последовательный канал, создаваемый нижними уровнями стека протоколов Bluetooth, очевиден для приложений с помощью профиля DUN. Таким образом драйвер модема на устройстве терминала не сознает, что это связывается по Bluetooth. Приложение на устройстве терминала столь же не сознает, что не подключено к устройству шлюза кабелем.

Профиль гарнитуры описывает, как гарнитура с поддержкой Bluetooth должна связаться с компьютером или другим bluetooth-устройством (таким как мобильный телефон). Когда соединено и сконфигурировано, гарнитура может действовать как аудиовход удаленного устройства и вывести интерфейс.

Кабельный заменяющий профиль твердой копии описывает, как отправить представленные данные по ссылке Bluetooth к устройству, такому как принтер. Несмотря на то, что другие профили могут использоваться для печати, HCRP особенно разработан для поддержки приложений твердой копии.

Профиль обмена родового объекта обеспечивает универсальный проект других профилей с помощью протокола OBEX и определяет роли клиента и сервера для устройств. Как со всеми транзакциями OBEX, профиль обмена родового объекта предусматривает, что клиент инициирует все транзакции. Профиль, однако, не описывает, как приложения должны определить объекты обмениваться или точно как приложения должны реализовать обмен. Эти подробные данные оставляют профилям, зависящим от профиля обмена родового объекта, а именно, объектное нажатие, передача файлов и профили синхронизации.

Объектный профиль нажатия определяет роли сервера нажатия и клиента нажатия. Эти роли походят и должны взаимодействовать с ролями серверного и клиентского устройства, которые определяет профиль обмена родового объекта. Объектное нажатие профилирует внимание на узкий диапазон объектных форматов для максимальной функциональной совместимости. Наиболее распространенным из приемлемых форматов является формат vCard. Если приложение должно обмениваться данными в других форматах, это должно использовать другой профиль, такой как профиль передачи файлов.

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

Профиль синхронизации является другим зависимым профиля обмена родового объекта. Это описывает, как приложения могут выполнить синхронизацию данных, такой как между карманным персональным компьютером (PDA) и компьютером. Не удивительно, профиль синхронизации, также, определяет роли устройства клиента и сервера. Профиль синхронизации фокусируется на обмене данными управления персональными данными (PIM), такими как список ожидающих выполнения задач, между устройствами с поддержкой Bluetooth. Типичное использование этого профиля было бы приложением, синхронизирующим Ваш компьютер и Ваши версии PDA’s Ваших данных PIM. Профиль также описывает, как приложение может поддерживать автоматическую синхронизацию данных — другими словами, синхронизация, происходящая, когда устройства обнаруживают друг друга, а не при команде пользователя.