Книги, научные публикации Pages:     | 1 | 2 | 3 |

СОДЕРЖАНИЕ РАЗДЕЛ 1. ВВЕДЕНИЕ.............................................................................................................. 6 1.1. Происхождение ...

-- [ Страница 2 ] --

2) Общий процесс Для активизации режима тестирования (РТ) на тестируемое устройство (Device 3) Конечный автомат Under Test Ч DUT) посылаются РТ-сообщения. Тестируемое устройство всегда 4) Машина состояний является подчиненным. Администратор связи устройства должен быть способен 5) Сигнализация получать эти сообщения в любое время. Если активизация режима тестирования 6) Опции параметров конфигурации 7) Базовые элементы обслуживания Введение Этот подраздел технических требований Bluetooth дает обзор протокола управле ния логической связью и адаптацией. Протокол L2CAP расположен над Baseband протоколом и находится на уровне передачи данных (рис. 2.26). Функции L2CAP:

Х СО- и CL- услуги передачи данных для протоколов высших уровней Х Мультиплексирование протоколов Х Сегментация и реассемблирование Х Групповая абстракция L2CAP позволяет высокоуровневым протоколам и приложениям передавать и принимать пакеты данных L2CAP длиной до 64 кбайт.

Рис. 2.28. Структура ACL заголовка полезной информации для многослотовых пакетов 2-битное поле логического канала (L_CH), определенное в таблице 2.18, отлича ет пакеты L2CAP от пакетов LMP. Остальные коды зарезервированы для последу ющего использования.

Таблица 2. L СНкод Логический канал Информация Q0 Зарезервирован Зарезервирован для последующего использования 01 L2CAP Продолжение пакета L2CAP Ю L2CAP Начало пакета L2CAP 11 LMP Пакет LMP Рис. 2.26. Уровни связи между устройствами Bluetooth В разделе Baseband определено два типа линий связи: синхронные с установле- В ACL заголовке 1-битное поле Поток управляется контроллером связи и обыч но его значение равно 1. Его значение равно 0, когда по ACL линии связи больше нием соединения и асинхронные без установления соединения. SCO линии связи поддерживают голосовой трафик в реальном времени, используя зарезервирован- не будет передаваться L2CAP трафик. Передача пакета L2CAP со значением поля ную полосу пропускания. ACL линии связи поддерживают трафик на основе мак- Поток, равным 1, возобновляет поток входящих пакетов L2CAP.

симальных усилий (best effort).

Функциональные требования L2CAP Протокол L2CAP определен только для ACL линий связи и не обеспечивает Функциональные требования L2CAP включают мультиплексирование протоко поддержки SCO линий связи.

лов, сегментацию и реассемблирование (Segmentation and Reassembly - SAR), a Для ACL линий связи не допускается использование пакетов AUX1. Этот тип также групповое управление. На рис. 2.29 изображено размещение L2CAP в стеке пакетов не поддерживает проверку целостности данных с помощью циклического протоколов Bluetooth. L2CAP находится над протоколом Baseband и взаимодейст избыточного кода. Поскольку L2CAP зависит от проверки целостности на baseband уровне, пакеты AUX1 никогда не используются для транспортировки данных вует с другими протоколами, такими как SDP, RFCOMM и TCS.

L2CAP. Реализация L2CAP должна быть приемлемой для устройств с ограниченными Формат ACL заголовка полезной информации рассмотрен ниже. На рис. 2.27 вычислительными ресурсами. Требования к памяти для реализации протокола так изображен заголовок полезной информации, использующийся для однослотовых же должны быть сведены к минимуму.

пакетов, а на рис. 2.28 изображен заголовок, использующийся для многослотовых Сложность протокола должна быть приемлема для персональных компьютеров, пакетов. Разница заключается только в длине поля. Тип пакета (в поле baseband PDA, цифровых сотовых телефонов, беспроводных гарнитур и других беспровод заголовка;

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

Х Мультиплексирование протоколов L2CAP поддерживает мультиплексирование протоколов, т.к. протокол Baseband не поддерживает поле Тип, распознающее протоколы высших уровней, которые мультиплексируются выше. Baseband мультиплексирует потоки SCO и ACL. Про Рис. 2.27. Структура ACL заголовка полезной информации для однослотовых пакетов токол L2CAP должен мультиплексировать протоколы высших уровней, такие как слотового.

протокол обнаружения услуг, RFCOMM и протокол управления телефонией Обший процесс (рис. 2.29). Мультиплексирование протоколов означает направление пакетов дан- Протокол L2CAP базируется на понятии каналов. Их использование определяет ных на соответствующий протокол более высокого уровня.

идентификатор канала (Channel IDentifier Ч CID). Идентификатор канала Ч это Х Сегментация и реассемблирование конечная точка канала L2CAP, использующаяся для демультиплексирования вхо По сравнению с проводными физическими средами передачи данных, пакеты дящего пакета.

данных, определенные протоколом Baseband, ограничены'в размере. L2CAP паке ты большой длины должны быть сегментированы на многочисленные baseband па- Идентификаторы каналов кеты меньшей длины до передачи. Подобным образом, принимаемые baseband па- Идентификаторы от 0x0001 до 0x003F заразервированы для специальных функ кеты могут быть реассемблированы в один L2CAP пакет после простой проверки ции. Нулевой идентификатор (0x0000) определен как недопустимый идентифика целостности. Функциональные возможности сегментации и реассемблирования тор и никогда не должен использоваться для конечной точки назначения. В табли необходимы для поддержки протоколов, которые используют пакеты, длина кото- це 2.19 приведены другие зарезервированные CID.

рых превышает длину baseband пакетов.

Таблица 2.19. Распределения СШ Х Качество услуг Процесс установления соединения L2CAP позволяет проводить обмен информа- Описание его цией относительно качества услуг (QoS), ожидаемого между двумя модулями 0x0000 Нулевой идентификатор Bluetooth. Каждая реализация L2CAP должна контролировать ресурсы, используе 0x0001 Канал сигнализации мые протоколом.

0x0002 Канал приема без установления соединения 0x0003-0x003F Зарезервированный 0x0040-0xFFFF Динамически распределенный Операции между устройствами На рис. 2.30 приведен пример использования СШ при связи между соответст вующими равноправными объектами L2CAP на отдельных устройствах. Ори ентированные на соединение каналы передачи данных представляют связь между двумя устройствами, где идентификатор канала идентифицирует каж дую конечную точку канала. Каналы без установления соединения ограничи вают поток данных до однонаправленного. Эти каналы используются для под держки группы каналов, где СШ на источнике представляет одно или не сколько удаленных устройств. Существует также определенное количество CID, зарезервированных для особых целей. Примером зарезервированного ка Рис. 2.29. Схема мультиплексирования протоколов на уровне L2CAP нала является канал сигнализации. Этот канал используется для установления каналов передачи данных, ориентированных на соединение, и для определения Х Группы изменений характеристик этих каналов. Поддержка каналов сигнализации в Многие протоколы используют концепцию группы адресов. Протокол Baseband объектах L2CAP обязательна. Другие СШ зарезервированы для всех входя поддерживает концепцию пикосети, т.е. группы устройств, синхронно меняющих щих потоков данных без установления соединения. В примере, приведенном частоту, используя одни часы. Групповая абстракция L2CAP позволяет проводить на рис. 2.30, СШ используется для представления группы, состоящей из уст эффективное отображение групп протоколов на пикосети.

ройства 3 и устройства 4. Данные, посланные от этого СШ, направляются на Следует отметить свойства, которые НЕ поддерживает L2CAP:

Удаленный канал, зарезервированный для потока данных без установления со Х L2CAP не передает голос, предназначенный для SCO линий связи;

единения.

Х L2CAP не выполняет повторные передачи и вычисление контрольной суммы;

В таблице 2.20 описаны различные каналы и соответствующие идентификаторы Х L2CAP не поддерживает надежного широковещательного канала;

источника и пункта назначения.

Х L2CAP не поддерживает концепции глобального группового имени.

Таблица 2. Тип канала Локальный CID Удаленный CID Ориентированный Динамически распределенный Динамически распределенный на соединение Без установления соединения Динамически распределенный 0х0002(фиксированный) Канал сигнализации 0x0001 (фиксированный) 0x0001 (фиксированный) В пакете определены следующие поля:

Х Длина (16 бит) Ч указывает размер полезной информации в байтах, исключая длину заголовка L2CAP. Это поле обеспечивает простую проверку целостности ре- ассемблированного L2CAP пакета на приемной стороне.

Х ID канала (16 бит) Ч идентифицирует конечную точку канала назначения пакета.

Х Полезная информация (до 65535 байт) Ч содержит полезную информацию, полученную от протокола верхнего уровня (исходящий пакет), или переданную на протокол верхнего уровня (входящий пакет).

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

На рис. 2.32 изображена структура CL пакета, который используется для переда чи данных, ориентированных на группы.

Рис. 2.30. Каналы между устройствами Диаграмма состояний В этом разделе описана диаграмма состояний протокола L2CAP для канала с уста новлением соединения. Диаграмма состояний определяет состояния, события, вле кущие смену состояний, а также действия, которые должны быть выполнены в от вет на события. Диаграмма состояний не определена для канала сигнализации и для однонаправленного канала.

Формат пакетов данных Протокол L2CAP основан на пакетах, но следует модели связи, основанной на Групповые каналы ненадежны. Протокол L2CAP не гарантирует, что данные, пе каналах. Канал представляет собой поток данных между объектами L2CAP на от редаваемые группе, достигнут каждого члена этой группы.

даленных устройствах. Каналы могут быть ориентированными на соединение и без Данные, ориентированные на группу, передаются всем членам группы без ис установления соединения. Все поля пакета используют прямой порядок байтов.

ключения. Локальное устройство не может быть членом группы.

Канал ориентированный на соединение В пакете определены следующие поля:

Пакеты данных, ориентированные на соединение, используются для поддержки Х Длина (16 бит) Ч указывает размер полезной информации, плюс PSM поле (в надежного сеанса связи point-to-point. На рис. 2.31 изображен формат L2CAP па байтах), исключая длину заголовка L2CAP.

кета в канале, ориентированном на соединение.

Х ID канала (16 бит) Ч указывает групповой пункт назначения пакета.

Опции параметров конфигурации Х Мультиплексор протоколов/служб (Protocol/Service Multiplexer Ч PSM) Опции являются механизмами расширения возможностей, необходимых для вы (минимум 16 бит) Ч значения PSM имеют два интервала. Значения первого интер полнения различных требований подключения. Опции передаются в форме эле вала назначены Bluetooth SIG и служат признаком определенного протокола. Зна ментов информации, которые включают тип опции, длину опции, и одно или более чения второго диапазона динамически распределены и используются вместе с про поле данных опции (рис. 2.34).

токолом обнаружения услуг.

Х Полезная информация (до 65535 байт) содержит полезную информацию, ко торая должна быть распределена всем членам группы.

Интерфейс групповых служб L2CAP обеспечивает механизм для простого уп равления группами, включая создание группы, добавление новых членов в группу, исключение членов из группы.

Сигнализация В этом разделе описаны команды сигнализации, которыми обмениваются два объ Опция содержит следующие поля:

екта L2CAP на удаленных устройствах. Все команды сигнализации передаются на Х Тип (8 бит) Ч это поле определяет конфигурируемые параметры.

CID 0x0001. Реализация L2CAP определяет адрес устройства Bluetooth, которое Х Длина (8 бит) Ч это поле определяет число байт в полезной информации. Ес передает команды. В одном L2CAP пакете может быть передано несколько команд.

ли тип опции не имеет полезной информации, то его длина равна нулю.

На рис. 2.33 изображен общий формат всех команд сигнализации.

Х Данные опции (16 бит) Ч содержимое этого поля зависит от типа опции.

Типы опций:

Х Модуль максимальной передачи Х Опция времени ожидания сброса Х Опция качества обслуживания Базовые элементы обслуживания Этот раздел представляет абстрактное описание услуг, предлагаемых L2CAP, на ос нове базовых элементов и параметров обслуживания. Интерфейс обслуживания ну жен для тестирования. Интерфейс описан независимо от использования какой-либо определенной реализации. Все значения данных используют прямой порядок байтов.

Рис. 2.33. Общий формат команд сигнализации, передаваемых между объектами L2CAP на удаленных устройствах 2.2.5. Протокол обнаружения услуг Протокол обнаружения услуг (Service Discovery Protocol Ч SDP) является меха Пакет команд сигнализации содержит следующие поля:

низмом, посредством которого устройства Bluetooth обнаруживают доступные ус Х Код (8 бит) Ч определяет тип команды. Если принимающая сторона не рас луги, а также характеристики этих услуг.

познает поля Код, в ответ посылается пакет, отклоняющий всю команду.

Термин луслуги включает в себя широкий спектр приложений или ресурсов.

Х Идентификатор (8 бит) Ч используется для согласования запроса с ответом.

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

ройство использует такое же значение в своем ответе. Для каждой команды должен Услуги могут быть обычными:

использоваться отдельный Идентификатор.

Х Печать Х Длина (16 бит) Ч указывает только размер поля данных команды сигнализа Х Поисковая связь ции (в байтах). Не включает количество байт в полях Код, Идентификатор и Х Факсимильная связь Длина.

Возможны также различные виды доступа к информации:

Х Данные (0 и более байт) Ч это поле с переменной длиной обнаруживается с Х Организация телеконференций помощью поля Длина. Формат поля Данные определяет поле Код.

Х Сетевые мосты Если клиент или приложение, связанное с клиентом, решает использовать услу Х Точки доступа гу, оно должно создать отдельное соединение с провайдером услуг. SDP обеспечи Х Возможности электронной коммерции (eCommerce) вает механизм для обнаружения услуг и их атрибутов (включая протоколы доступа Кроме того, существуют другие возможности:

к услугам), но не обеспечивает механизм использования этих услуг.

Х Получение доступа к услугам На каждое устройство Bluetooth приходится не более одного SDP-сервера.

Х Управление доступом к услугам (Если устройство Bluetooth работает только как клиент, ему не нужен SDP-cep Х Рекламирование услуг вер.) Одно устройство Bluetooth может функционировать и как SDP-клиент, и Частью функции протокола обнаружения услуг является обеспечение средств как SDP-сервер. Если многочисленные приложения на устройстве предостав обнаружения и получения протоколов, методов доступа, драйверов, и других ко ляют услуги, SDP-сервер устройства может работать от лица провайдера этих дов, необходимых для использования услуг. Кроме того, через этот протокол кон услуг.

тролируются другие атрибуты, такие как: управление доступом к услугам, рекла Подобным образом, многочисленные приложения клиента могут использовать мирование услуг, выбор между конкурирующими услугами, оплата услуг и т.п.

SDP-клиент для запроса серверов от лица приложений клиента.

В разделе SDP интерес представляют следующие подразделы:

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

2) Представление данных Когда сервер становится доступен, потенциальный клиент должен быть уведомлен 3) Описание протокола об этом без использования SDP, для того чтобы он мог использовать SDP для за 4) Определения атрибутов услуг проса сервера о его услугах. Подобным образом, когда сервер покидает зону дейст вия или становится недоступен по какой-либо причине, SDP не используется для Общий обзор уведомления об этом клиента. Однако, клиент может использовать SDP для запро Механизм обнаружения услуг предоставляет приложениям клиента средства для са сервера, и если сервер не отвечает на запросы, клиент заключает, что сервер ему обнаружения услуг, предоставленных приложениями сервера, а также атрибутов недоступен.

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

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

Описание протокола Протокол обнаружения услуг является простым протоколом с минимальными тре бованиями к основному транспорту. SDP использует модель запрос/ответ, где каждая транзакция состоит из одного PDU запроса и одного PDU ответа. Однако, нет гарантии, что серии запросов приведут к возвращению ответов в том же самом порядке.

Когда SDP использует транспортный протокол Bluetooth L2CAP, в одном L2CAP пакете может быть передано несколько SDP PDU, но в определенный мо мент времени только один L2CAP пакет за соединение к данному SDP серверу мо жет ожидать выполнения. Другими словами, клиент должен получать ответ на каждый запрос до того, как он сделает следующий запрос в этом же L2CAP соеди нении. Ограничение SDP к передаче одного непризнанного запроса обеспечивает простую форму управления потоком данных.

Рис. 2.35. SDP-взаимодействие клиента и сервера ент может получать информацию из записи с помощью SDP-запроса (рис. 2.35).

Протокол RFCOMM обеспечивает эмуляцию последовательных портов по про Порядок передачи байтов токолу L2CAP. Протокол основан на стандарте ETSI TS 07.10.

Протокол обнаружения услуг передает многобайтовые поля в обратном порядке байтов, при котором сначала передаются наиболее значимые байты, а потом наиме- RFCOMM эмулирует последовательные порты EIA/TIA-232 (ANSI/TIA/EIA 232-F-1997) со встроенной схемой для безмодемной эмуляции. Эмуляция также нее значимые.

Формат PDU включает передачу состояния цепи передачи голосовых сигналов. В большинстве Каждая протокольная единица обмена протокола SDP состоит из заголовка систем RFCOMM будет частью драйвера порта, который включает объект эмуля PDU, за которым следуют специальные параметры PDU. Заголовок состоит из ции последовательного порта.

трех полей: PDU ID, ID транзакции и длина параметра (рис. 2.36).

Фактическое управление потоком данных между RFCOMM и нижним уровнем L2CAP зависит от конкретной реализации. RFCOMM имеет виртуальный меха низм управления потоком данных.

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

Х Устройства типа 1 Ч оконечные точки связи, такие как компьютеры и принте ры.

Х Устройства типа 2 Ч часть сегмента связи;

например, модемы.

2.2.7. Взаимодействие с IrDA Определения атрибутов услуг Беспроводной технологией Bluetooth был принят протокол инфракрасного объект В раздел SDP Ядра технических требований Bluetooth включены только классы ного обмена (Infrared OBject EXchange - IrOBEX, сокращенно ОВЕХ). Bluetooth услуг, которые непосредственно поддерживают SDP-сервер. Дополнительные реализация OBEX предлагает такие же возможности для приложений, как и в ие классы услуг определены в разделе Профили. Вероятно, что последующие модер рархии протокола IrDA. Он является протоколом высокого уровня, который рабо низации технических требований Bluetooth будут иметь дополнительные классы тает с абстракциями данных (т.е. объектами).

услуг и модификации уже существующих.

Целью авторов этого раздела технических требований Bluetooth было продемон Интерфейсы связи стрировать, что можно разрабатывать приложения, которые хорошо функциониру Чтобы усовершенствовать большое количество современных коммуникацион ют как РАДИОЧАСТОТНЫЕ и как ИНФРАКРАСНЫЕ средства передачи дан ных приложений беспроводная технология Bluetooth должна взаимодействовать с ных с малым радиусом действия. Каждая среда имеет свои преимущества и недо существующими структурами протоколов и приложений.

статки, и некоторые приложения могут работать в обеих средах.

Технические требования Bluetooth описывают четыре адаптации:

Этот раздел определяет точку пересечения, где могут сходиться беспроводная 1)RFCOMM технология Bluetooth и приложения IrDA. Этой точкой пересечения является про 2) Взаимодействие с IrDA 3) Управление телефонией токол ОВЕХ.

4) Требования к взаимодействию для использования Bluetooth в качестве WAP Протокол ОВЕХ может передавать объект, используя операции Put и Get. Один bearer1.

объект может быть передан в одном или нескольких запросах Put или ответах Get.

Модель оперирует и информацией об объекте (т.е. типом), и непосредственно са 2.2.6. RFCOMM мим объектом.

RFCOMM Ч это последовательный протокол связи. Создатели приложений часто Существует два метода реализации протокола ОВЕХ в системе Bluetooth. Про используют этот протокол при проектировании функции, которая использует по токол ОВЕХ может быть реализован с использованием возможностей, определен следовательный кабель связи.

ных протоколом RFCOMM или TCP/IP.

В устройствах Bluetooth при реализации ОВЕХ с использованием RFCOMM 'Bearer Ч однонаправленный канал передачи данных. Совокупность средств передачи информа Должны быть выполнены следующие требования:

ции и среды распространения, используемых в процессе информационного обмена 1) Устройство, поддерживающее ОВЕХ, должно быть способно функциониро вать как клиент, как сервер, или и то и другое.

2) Все серверы, одновременно функционирующие на устройстве должны ис пользовать отдельные каналы RFCOMM сервера.

3) Приложения (служба/сервер), использующие ОВЕХ, должны быть способны регистрировать надлежащую информацию в базу данных обнаружения услуг. Эта информация необходима для различных прикладных профилей, и определена в технических требованиях каждого профиля.

Для создания надежных услуг, ориентированных на соединение, протоколу ОВЕХ ставится в соответствие протокол TCP/IP. Этот раздел технических требо ваний не определяет, как TCP/IP ставится в соответствие беспроводной связи Bluetooth. Устройства Bluetooth, которые поддерживают протокол ОВЕХ по TCP/IP, должны удовлетворять следующим требованиям:

1) Устройства, поддерживающие ОВЕХ, должны быть способны функциониро Рис. 2.37. Положение протокола TCS в стеке Bluetooth вать как клиент, как сервер, или и то, и другое.

2) Для сервера TCP порт с номером 650 назначен агентством по выделению 2.2.9. Требования к взаимодействию для использования Bluetooth в качестве имен и уникальных параметров протоколов Internet (Internet Assigned Number WAP Bearer Authority Ч IANA). Если назначенный номер не подходит, номер порта может при Протокол беспроводных.приложений (Wireless Application Protocol Ч WAP) спро нимать значение выше 1023. Однако рекомендуется использование номера TCP ектирован для обеспечения доступа в Интернет с устройств, имеющих те или иные порта (650), определенного IANA.

ограничения:

3) Клиент должен использовать номер порта (на стороне клиента), который на Х Полоса рабочих частот канала связи ходится вне диапазона 0-1023.

Х Объем памяти 4) Приложения (служба/сервер), использующие ОВЕХ, должны быть способны Х Производительность регистрировать надлежащую информацию в базу данных обнаружения услуг.

Х Возможности отображения Технические требования Bluetooth определяют три прикладных профиля, кото рые используют ОВЕХ (см. Профили): Х Устройства ввода 1) Профиль синхронизации В этом разделе рассматривается, как беспроводная технология Bluetooth может 2) Профиль передачи файлов быть использована как служба Bearer (однонаправленный канал передачи данных), 3) Профиль помещения объекта в стек а также определяются SDP записи, позволяющие обнаружение WAP серверов с их оборудованием.

2.2.8. Протокол управления телефонией Описываются требования к взаимодействию для использования беспроводной Протокол управления телефонией (Telephony Control Specification Ч TCS), явля технологии Bluetooth с протоколом point-to-point (PPP) в качестве однонаправ ется бит-ориентированным протоколом. Этот протокол определяет управление ленного канала передачи данных для приложений и протоколов WAP.

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

устройствами Bluetooth. Кроме того, он определяет процедуры управления мо 1) WAP клиент бильностью при работе с группами TCS-устройств Bluetooth.

2) WAP Ргоху/шлюз Протокол TCS обладает следующими функциональными возможностями:

3) WAP сервер Х Управление вызовом (Call Control Ч СС) Ч сигнализация для установления и WAP клиент Ч устройство, которое использует конечный пользователь. Это мо прекращения сеансов передачи голоса и данных между устройствами Bluetooth.

жет быть портативный компьютер или мобильный телефон. Отличительной осо Х Групповое управление (Group Management Ч GM) Ч сигнализация для упро бенностью WAP клиента является наличие дисплея и устройства ввода. WAP-кли щения управления группой устройств Bluetooth.

ент соединяется с WAP Proxy/шлюзом через беспроводную сеть.

Х TCS без установления соединения (ConnectionLess Ч CL) Ч условия для об WAP Proxy/шлюз работает как интерфейс между беспроводной сетью и сетью мена сигнальной информацией, не связанной с текущим запросом.

Интернет. Основной функцией модуля доступа (proxy) является обеспечение ус На рис. 2.37 показано положение протокола TCS в стеке протоколов Bluetooth.

луг разрешения DNS имен WAP клиенту и преобразование Интернет-протоколов и форматов содержимого в их WAP эквиваленты.

В некоторых случаях WAP Proxy/шлюз может включать функциональные воз 2.2.10.Интерфейс хост-контроллера Bluetooth можности сервера.

Интерфейс хост-контроллера (Host Controller Interface Ч HCI) обеспечивает еди WAP сервер выполняет функцию, идентичную функции сервера в сети Интер ный интерфейсный метод доступа к возможностям аппаратного обеспечения нет. Зачастую, WAP сервер является HTTP сервером.

Bluetooth.

Технические требования интерфейса хост-контроллера точно определяют как логическую, так и физическую работу этого интерфейса.

На рис. 2.39 показано расположение HCI в стеке протоколов Bluetooth.

функциональные технические требования Bluetooth HCI Введение Интерфейс хост-контроллера является эквивалентом кабеля, который соединяет модем с персональным компьютером. По такому интерфейсу проходят два различ ных класса информации. Первый Ч полезная информация, которая распространя лась бы между хостом и его системой связи, если бы они были в физическом кон такте (т.е. интегрированы вместе). Второй Ч информация управления и координа ции, необходимая для поддержки удаленной физической связи. HCI охватывает оба эти потока связи.

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

Интерфейс хост-контроллера обеспечивает единый интерфейсный метод полу чения доступа к возможностям аппаратных средств Bluetooth. Функциональные технические требования обеспечивают:

Х Общий обзор нижних уровней стека программного обеспечения Bluetooth и аппаратных средств Bluetooth.

Х Обзор транспортного уровня хост-контроллера.

Х Описание управления потоком данных, который используется между хостом и хост-контроллером.

Х Детали каждой команды HCI (параметры для каждой команды и списки собы тий, связанных с каждой командой).

Обзор нижних уровней стека программного обеспечения Bluetooth и аппаратных средств Bluetooth На рис. 2.40 изображены нижние уровни стека программного обеспечения Bluetooth. Программно-аппаратное обеспечение HCI выполняет HCI-команды для аппаратного обеспечения Bluetooth, имея доступ к baseband-командам, LM-коман Дам, регистрам состояния аппаратного обеспечения, регистрам управления и регис трам событий.

На рис. 2.41 изображена архитектура аппаратного обеспечения Bluetooth.

Контроллер связи состоит из программного и аппаратного обеспечения, которые выполняют baseband-обработку данных, и протоколов физического уровня, таких как ARQ-протокол и FEC-кодирование.

Транспортный уровень хост-контроллера описан для каждой физической среды в следующих трех разделах технических требований:

Х Транспортный уровень HCI USB;

Х Транспортный уровень HCI RS23;

Х Транспортный уровень HCI UART.

Управление потоком Управление потоком данных используется в направлении от хоста к хост-контролле ру. Оно позволяет избежать заполнения буфера данных хост-контроллера ACL-дан ными, предназначенными для удаленных устройств, которые не отвечают на запросы.

HCI команды Интерфейс хост-контроллера обеспечивает единый командный метод доступа к возможностям аппаратного обеспечения Bluetooth. Команды связи HCI дают воз можность хосту контролировать соединения с другими устройствами Bluetooth на канальном уровне. Эти команды обычно включают LM для обмена LMP-команда ми с удаленными устройствами Bluetooth.

2.2.11. Транспортный уровень HCI USB В этом разделе рассматриваются требования к интерфейсу универсальной последователь ной шины (Universal Serial Bus Ч USB) для аппаратных средств Bluetooth. Предполагает ся, что читатели знакомы с интерфейсом USB, проблемами конструкции USB, усовер шенствованным интерфейсом конфигурирования системы и управления энергопитанием Рис. 2.40. Нижние уровни стека программного обеспечения Bluetooth (Advanced System Configuration and Power Interface Ч ACPI), полной архитектурой Bluetooth, основами радио интерфейса, и с интерфейсом хост-контроллера Bluetooth. На рис. 2.42 приведена взаимосвязь между хостом и радио модулем Bluetooth.

CPU-ядро позволяет модулю Bluetooth обрабатывать требования запроса (inquiry) и вызова (page) без привлечения хост-устройства. Хост-контроллер мо жет быть запрограммирован на ответ определенными page-сообщениями и аутен тифицировать удаленные линии связи.

Обзор транспортного уровня HCI Между HCI драйвером и HCI контроллером находится транспортный уровень. На ноутбуке, например, этим транспортным уровнем может быть PC-карта или уни Рис. 2.42. Взаимосвязь между хостом и радио модулем Bluetooth Рис. 2.41. Аппаратная архитектура Bluetooth версальная последовательная шина.

Аппаратное обеспечение USB может быть реализовано двумя путями:

2.2.14. Тестирование Х Как USB адаптер (рис. 2.43);

Режим тестирования поддерживает тестирование передатчика и приемника Х Интегрировано в материнскую плату ноутбука.

Bluetooth. Это предназначено главным образом для сертификации и испытания на соответствие стандартам Радио и Baseband.

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

Тестированию посвящены три раздела технических требований:

Х Режим тестирования Bluetooth;

Х Требования на соответствие стандартам;

Х Интерфейс управления тестированием.

Рис. 2.43. Bluetooth USB адаптер компании Bluetake Режим тестирования Bluetooth Тестирование протокола используется, для проверки функциональных возможнос 2.2.12. Транспортный уровень HCI RS тей на самых нижних уровнях для всех приложений, компонентов и изделий Цель транспортного уровня HCI RS232 состоит в том, чтобы сделать возможным Bluetooth. Это испытание на соответствие нужно для того, чтобы полностью прове использование интерфейса хост-контроллера Bluetooth по одному физическому ин рить функционирование устройства Bluetooth.

терфейсу RS232 между хостом Bluetooth и хост-контролером Bluetooth (рис. 2.44).

Установка для тестирования состоит из тестируемого устройства (DUT) и тесте ра (при желании, может использоваться дополнительное измерительное оборудо вание). Тестер и DUT формируют пикосеть, где тестер действует как мастер и име ет полный контроль над процедурой тестирования. Тестируемое устройство дейст вует как подчиненное. Контроль производится по воздушному интерфейсу с ис пользованием команд протокола управления связью. Схема режима тестирования Рис. 2.44. Интерфейс между хостом и хост-контроллером Bluetooth (уровень HCI RS232) изображена на рис. 2.46.

Режим тестирования Ч это специальное состояние модели Bluetooth. Из сообра жений защиты, устройство в режиме тестирования не может поддерживать нор 2.2.13. Транспортный уровень HCI UART мальную работу. В этом состоянии не могут быть отправлены или получены дан Цель транспортного уровня универсального асинхронного приемопередатчика ные пользователя. Это делается для того, чтобы обезопасить, т.е. исключить не (Universal Asynchronous Receiver Transmitter Ч UART) HCI состоит в том, чтобы сделать возможным использование Bluetooth HCI по последовательному интер- санкционированное вхождение в режим тестирования и получения нежелательно фейсу между двумя UART на одной печатной плате (рис. 2.45). Транспортный уро- го доступа к информации.

Когда DUT-устройство выходит из режима тестирования, оно входит в режим вень UART HCI предполагает, что UART-связь не имеет линейных ошибок. Этот раздел описывает транспортный уровень UART (между хостом и хост-контролле- ожидания (Standby). После отключения питания, устройство Bluetooth должно вернуться в режим ожидания.

ром). Через этот уровень проходят HCI пакеты, содержащие команды, события и данные, но уровень не декодирует их.

2.2.15. Требования на соответствие стандартам Группа Bluetooth SIG имеет подписанное соглашение, по которому на все изделия, Удовлетворяющие техническим требованиям, выдается лицензия.

В этом разделе приведен обзор требований и программа квалификации Bluetooth. Программа квалификации Ч это процесс проверки изделия на соответ ствие техническим требованиям Bluetooth.

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

2.2.16. Интерфейс управления тестированием jCo всем приложениям, компонентам и изделиям Bluetooth применяются аттеста ционные испытания.

Интерфейс управления тестированием (Test Control Interface Ч TCI) Bluetooth используется при проверке выполнения протокольных требований Bluetooth для приложений, компонентов или изделий Bluetooth. Таким образом, интерфейс TCI используется для проверки реализованных функциональных возможностей следу ющих уровней:

Х Baseband;

Х LMP;

Х L2CAP;

Х HCI, если производитель требует поддержки HCI.

Рис. 2.46. Алгоритм режима тестирования 2.3. Заимствованные протоколы Х Аналитический совет программы квалификации Bluetooth (BQRB);

Технические требования Bluetooth используют несколько существующих протоко Х Администратор квалификации Bluetooth (BQA);

лов, которые применяются для различных целей на высших уровнях [1].

Х Квалификационное испытательное оборудование Bluetooth (BQTF);

Х Квалификационная группа Bluetooth (BQB).

2.3.1. Point-to-Point Схема квалификационного процесса Bluetooth изображена на рис. 2.47.

Беспроводная технология Bluetooth использует протокол point-to-point (PPP), разработанный проблемной группой проектирования Интернет (Internet Engineering Task Force Ч IETF). Протокол РРР должен работать поверх RFCOMM. Соединения point-to-point служат средством, позволяющим переме щать IP-пакеты с уровня РРР на уровень локальных сетей. Такие соединения ис пользуются при получении доступа в сеть Интернет через модем на основе комму тации, или через маршрутизатор по выделенной линии. Протокол point-to-point имеет три основных составляющих.

Инкапсуляция Инкапсуляция Ч это метод, используемый многоуровневыми протоколами, суть которого заключается в том, что каждый уровень добавляет свой заголовок в про токольную единицу обмена (PDU).

Протокол РРР обеспечивает средство для инкапсулирования дэйтаграмм2 через последовательные линии связи и предоставляет протокол инкапсуляции через бит ориентированные синхронные линии связи и через асинхронные линии связи с во вемью битами данных и без контроля на четность. Эти линии связи полнодуплекс Ные, но могут быть выделенными или с коммутацией каналов. Протокол point-to point использует высокоуровневый протокол управления линией связи (High-level Data Link Control Ч HDLC) в качестве основы для инкапсуляции. Инкапсуляция также предусматривает мультиплексирование различных протоколов сетево- Дэйтаграмма Ч это общее название для единиц данных, которыми оперируют протоколы без Рис. 2.47. Схема квалификационного процесса Установления соединения.

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

Протокол управления передачей Протокол управления линией связи Протокол управления передачей Ч это ориентированный на соединение протокол Протокол управления линией связи (Link Control Protocol Ч LCP) PPP обеспечи сквозной передачи данных, который приспособлен для уровневой иерархии прото вает метод для установления, конфигурирования, управления и завершения одно колов, которые поддерживают многосетевые приложения. Протокол TCP отправ ранговой связи. Протокол LCP включает четыре фазы:

ляет данные, полученные в форме IP-дейтаграмм или пакетов на приемный хост.

Х Установление связи и согласование конфигурации. Перед тем, как можно бу Кроме того, протокол TCP определяет процедуры для деления потока данных на дет поменять любую дэйтаграмму сетевого уровня (например, IP), протокол LCP пакеты, восстанавливая их в правильном порядке для получения исходного потока должен установить связь и согласовать конфигурирующие параметры. Эта фаза за данных на приемной стороне, и запрашивая повторную передачу для замены про вершается, когда конфигурирующий опознавательный пакет будет отправлен и по пущенных или поврежденных пакетов. Так как пакеты обычно доходят по сети Ин лучен обратно.

тернет до пункта назначения различными путями, они приходят в разное время и Х Определение качества передачи. Протокол LCP предусматривает фазу опре не по порядку. Все пакеты временно сохраняются, пока не придут запоздавшие па деления качества передачи, следующую сразу за фазой установления связи. На кеты, тогда они могут быть собраны в правильном порядке. Если полученный па этой фазе тестируется канал и определяется достаточно ли его качество для работы кет поврежден, он отвергается, и в ответ на запрос о повторной передаче повреж протокола сетевого уровня.

денный пакет высылается повторно.

Х Согласование конфигурации протокола сетевого уровня. Как только LCP за вершает фазу определения качества передачи, могут быть сконфигурированы про Протокол передачи дейтаграмм пользователя токолы сетевого уровня из семейства протоколов управления сетью.

Тогда как протокол TCP предполагает гарантированную доставку, протокол UDP Х Прекращение передачи. Протокол LCP может прекратить передачу в любое только передает отдельные сообщения на IP для передачи на основе максимальных время. Это может быть сделано по запросу пользователя, но может также произой усилий. Так как протокол IP не обладает высокой надежностью, нет гарантии кор ти по причине физических нарушений, таких как потеря несущей или отключение ректной доставки данных. Тем не менее, протокол UDP очень удобен для опреде таймера.

ленных типов связи, таких как быстрый поиск баз данных. Например, система имен доменов (Domain Name System Ч DNS) состоит из набора распределенных баз дан Протокол управления сетью ных, которые предоставляют услуги, которые проводят соответствие между упро Использование линий связи point-to-point может создать дополнительные пробле щенными доменными именами и их IP адресами. Протокол UDP подходит для про мы с сетевыми протоколами. Например, распределение и управление IP адресами, стого обмена сообщениями между приложениями и этими сетевыми ресурсами.

проблемы даже в среде LAN, особенно сложны по линиям связи point-to-point с коммутацией каналов. Эти проблемы решаются с помощью семейства протоколов Интернет-протокол управления сетью (Network Control Protocol Ч NCP).

Интернет-протокол доставляет дэйтаграммы между различными сетями через мар В беспроводных сетях Bluetooth протокол point-to-point работает поверх шрутизаторы, которые обрабатывают пакеты при передаче от одной автономной RFCOMM для обеспечения последовательных линий связи point-to-point, напри системы (Autonomous System Ч AS) на другую. Каждое устройство в автономной мер, между подвижными устройствами и точками доступа к LAN. Протокол РРР системе имеет уникальный IP адрес. Протокол IP добавляет свой собственный за является средством, позволяющим забирать IP пакеты на/из РРР уровень и пере головок и контрольную сумму для того, чтобы данные были направлены правиль давать их на LAN, например, для предоставления пользователю доступа к корпора но. Этот процесс поддерживается наличием направляющих корректирующих сооб тивной электронной почте.

щений, которые хранят таблицы адресов на каждом маршрутизаторе. В зависимос ти от набора подсетей, включенных в домен управления, используется несколько 2.3.2. TCP/UDP/IP типов корректирующих сообщений. Таблицы маршрутизации регистрируют раз Протокол управления передачей (Transmission Control Protocol Ч TCP), протокол личные узлы в подсети, а также маршруты между узлами. Если пакет данных передачи дейтаграмм пользователя (User Datagram Protocol Ч UDP) и Интернет слишком велик для принятия узлом назначения, он будет сегментирован на мень протокол (Internet Protocol Ч IP) определены IETF и используются для связи по се шие пакеты с помощью высокоуровневого протокола TCP.

ти Интернет. Они относятся к числу самых используемых протоколов. Эти протоко- доставления такого рода информации и услуг. Обычно потребителями информации Реализация этих стандартов техническими требованиями Bluetooth позволяет WAP порталов являются пользователи сотовых телефонов, PDA и ноутбуков.

организовать связь с другими устройствами, подключенными к сети Интернет. Ус тройство Bluetooth, будь то сотовая гарнитура или точка доступа к LAN, использу- На рис. 2.49 изображен мобильный телефон Sony-Ericsson T68i, поддерживаю ется как мост в Интернет. Протоколы TCP, IP и РРР используются для всех мо- щий протоколы WAP, Bluetooth.

делей использования мост в Интернет. Протоколы UDP, IP и РРР также могут выполнять роль транспортного механизма для протокола беспроводных приложе ний (WAP).

2.3.3. ОВЕХ IrOBEX (сокращенно Ч ОВЕХ) является протоколом сеансового уровня, разрабо танным ассоциацией передачи данных в инфракрасном диапазоне (IrDA). Его це лью является поддержка простого, поэтапного обмена объектами. Протокол ОВЕХ, обеспечивающий функциональность, сходную с протоколом передачи гипертексто вых файлов (HyperText Transfer Protocol Ч HTTP), использует модель клиента сервера, не зависит ни от транспортного механизма, ни от транспортного API-ин Рис. 2.49. Мобильный телефон Sony-Ericsson T68i терфейса. Наряду с самим протоколом Ч грамматикой для ОВЕХ-переговоров между устройствами Ч ОВЕХ дает также модель для представления объектов и операций. Кроме того, ОВЕХ определяет оглавление папок, которое используется Обычно, эти устройства имеют маленькие экраны, поэтому информация должна для просмотра содержимого папок, находящихся на удаленных устройствах. быть представлена в формате no-frills (без излишеств). Кроме того, пропускная К устройствам, использующим протокол ОВЕХ, относятся мобильные телефо- способность ограничивает современные услуги сотовой связи, поэтому информа ны, PDA, портативные сканеры и т.д. На рис. 2.48 изображен портативный сканер ция должна быть оптимизирована для портативных устройств. Для получения ин Capshare 910 компании Hewlett-Packard, который может передавать документы на формации в такой форме Web-сайты оснащены упрощенной версией языка HTML, мобильные телефоны через ОВЕХ, и отправлять их на другие устройства, такие которая называется WML (Wireless Markup Language Ч язык разметки для беспро как факсы или устройства для чтения электронной почты. водных систем). Язык WML предназначен для создания Интернет страниц с син таксисом, соответствующим спецификации XML3.

Достоинство WAP заключается в том, что он охватывает многочисленные стан дарты воздушных линий связи (airlink) и, в соответствие с традициями Интернет, позволяет издателям содержимого и разработчикам приложений не беспокоиться о специальном механизме доставки. Архитектура WAP определена на основе сете вых протоколов, форматах содержимого и общих служб. Этот подход приводит к гибкой архитектуре клиент-сервер, которая может быть реализована различны ми способами, а также обеспечивает взаимодействие и мобильность в сетевых ин терфейсах. На рис. 2.50 изображен стек протоколов WAP.

Рис. 2.48. Портативный сканер Capshare 910 компании Hewlett-Packard WAP решает проблему использования Интернет-стандартов, таких как HTML, HTTP, TLS и TCP в мобильных сетях. Эти протоколы неэффективны, требуют пе 2.3.4. WAP редачи большого количества преимущественно текстовых данных. Web-содержи Протокол беспроводных приложений (WAP) является стандартом для беспровод- мое, написанный с помощью HTML как правило не может быть эффективно отоб ного доступа к информационным и сервисным ресурсам Интернет с цифровых уст- ражено на малогабаритных экранах миниатюрных мобильных телефонов и пэйд ройств, таких как сотовые телефоны, PDA и т.д. К наиболее распространенным ин- Жеров.

формационным службам, доступных с помощью WAP, относятся новости, курс ак ции, прогноз погоды, расписание полетов и корпоративные извещения. Специаль- XML - Extensible Markup Language Ч расширяемая спецификация языка, предназначенного Для создания Интернет страниц ные Web-сайты, называемые WAP порталами, специально форматированы для пре- д,1Я защиты конфиденциальности приложений электронной коммерции и скрытых вычислений.

Скрытое вычисление Ч это способность получать доступ и управлять функцио нальными возможностями компьютера с равноправных мобильных устройств.

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

2.3.5. WAE WAP приложения построены в среде беспроводных приложений (Wireless Application Environment Ч WAE), которая строго следует модели доставки Web содержимого, но с добавлением функций шлюза. На рис. 2.51 сопоставляются тра диционная Web-модель и WAE-модель. Все содержимое определено в форматах, подобных стандартным Интернет-форматам, и транспортируется с использовани ем стандартных протоколов, принятых во всемирной паутине, наряду с исполь Рис. 2.50. Стек протоколов WAP зованием оптимизированных HTTP-подобных протоколов в беспроводной среде Более того, HTTP и TCP не оптимизированы для неустойчивого покрытия, дли- (т.е. WAP). Архитектура разработана с учетом того, что мобильные терминалы тельных задержек и ограниченной пропускной способности, свойственных беспро- имеют ограниченный объем памяти и возможности процессора. Поддержка сетей с водным сетям. HTTP переводит свои заголовки и команды в неэффективный текс- низкой пропускной способностью и большими задержками также включена в архи товый формат, вместо сжатого двоичного формата. Беспроводные службы, исполь- тектуру. Там где существующие стандарты не подходят вследствие уникальных зующие эти протоколы, зачастую медленны, дорогостоящи и сложны в использова- особенностей малогабаритных беспроводных устройств, WAE модифицирует стан нии. Использование стандарта защиты TLS также проблематично, так как клиент и дарты, не теряя преимуществ Интернет технологии. Основные элементы модели сервер обмениваются большим количеством сообщений. WAE:

WAP оптимизирован для решения всех этих проблем. Он использует двоичную Х Агент пользователя - Эти программные компоненты на стороне клиента передачу для большего сжатия данных и оптимизирован для длительных задержек обеспечивают конечному пользователю специальные функциональные возможнос и невысокой пропускной способности. WAP-сеансы справляются с неустойчивым ти. Примером агента пользователя является браузер (программа ускоренного про покрытием и могут работать по самым различным беспроводным транспортам, ис- смотра), который выводит на экран содержимое, загружаемое из сети Интернет. В пользуя протокол IP где возможно, а другие оптимизированные протоколы, где ис- этом случае, агент пользователя интерпретирует содержимое сети, полученное по пользование IP невозможно. Язык WML, используемый при создании WAP-содер- унифицированному указателю информационного ресурса (Uniform Resource жимого, позволяет оптимально использовать малогабаритные экраны и допускает Locator - URL). WAE включает агентов пользователя для двух основных типов простое управление одной рукой, без полной клавиатуры;

он имеет возможность стандартного содержимого: кодированный язык разметки для беспроводных сис расширения от двухстрочного текстового дисплея до цветных графических диспле- тем (WML) и компилируемый WML-скрипт (Wireless Markup Language Script - ев, которыми обладают смарт-телефоны и коммуникаторы.

WMLScript).

Существуют две причины, по которым WAP подходит для среды Bluetooth: до- Х Генераторы содержимого - Приложения или услуги на сервере, которые мо ставка информации и скрытое вычисление (hidden computing). При передаче ин гут принять форму CGI-скриптов (Common Gateway Interface - общий шлюзовой формации, с использованием беспроводной технологии Bluetooth, WAP клиент об интерфейс), которые создают стандартные форматы содержимого в ответ на запрос- наруживает наличие WAP сервера, используя протокол обнаружения услуг (SDP).

агентов пользователя на мобильном терминале. WAE не определяет какого-либо При обнаружении услуг определяется адрес WAP сервера. Когда клиент получает определенного генератора содержимого, так как ожидается, что в будущем их коли адрес, он устанавливает соединение с сервером и может получать доступ к инфор чество сильно увеличится.

мации или услугам, предоставленных этим сервером на основе операций push/pull.

Х Стандартное кодирование содержимого Ч Это кодирование содержимого поз Кодирование и аутентификация обеспечиваются протоколом защиты уровня бес воляет агенту пользователя WAE (например, браузеру) легко управлять Web-co- проводной передачи (Wireless Transport Layer Security Ч WTLS), который служит Держимым. Стандартное кодирование содержимого включает сжатое кодирование сервер, предоставлять пользователям доступ к возможностям устройств и перифе рийному оборудованию, и взаимодействовать с пользователем без двукратного об ращения к сетевому серверу.

Кроме WML и WMLScript, поддерживаются другие форматы содержимого для WAP- Это vCard, vCalendar, vMessage и vNote. Эти и другие компоненты являются частью среды беспроводных приложений.

2.3.6. Форматы содержимого VCard и vCalendar являются открытыми спецификациями, разработанными орга низацией Versit Consortium, которые в настоящее время контролируются консор циумом почты Интернет (Internet Mail Consortium Ч IMC), а его дальнейшая раз работка производится проблемной группой проектирования Интернет. Эти специ фикации определяют формат электронных визитных карточек и содержимого пер сонального календаря и расписания, соответственно. vCard и vCalendar не опреде ляют никакого транспортного механизма. Они определяют только формат, в кото ром передаются данные между устройствами.

vCalendar Спецификация vCalendar определяет транспортно- и платформо- независимый формат для обмена календарной информацией и информацией о расписании. Фор мат vCalendar (рис. 2.52) включает информацию о событиях и сообщениях, обычно используемых приложениями, такими как личная информационная система (Personal Information Manager Ч PIM) и программы группового планирования.

Формат vCalendar обеспечивает совместимый и простой способ обмена инфор мацией. Базовый набор свойств vCalendar включает такие расширенные свойства как присоединение элементов, звуковые и e-mail напоминания, классификация со бытий. К элементам, которые могут быть присоединены к событию, относится эле ктронная визитная карточка отправителя, называемая vCard. Кроме того, техниче Рис. 2.51. Стандартная модель доставки Web-содержимого (сверху) и модель WAE (снизу) ские требования vCalendar обеспечивают взаимодействие между различными при ложениями календаря и расписания для планирования встреч через Интернет или для WML, кодирование байт-кода (машинно-независимый код, генерируемый корпоративные сети. С принятием специальной рабочей группой Bluetooth этого Java-компилятором) для WMLScript, стандартные форматы изображений, а также протокола, vCalendar может выполнять свои функции внутри пикосети.

заимствованные форматы деловых и календарных данных (vCard и vCalendar).

Х Приложения беспроводной телефонии (Wireless Telephony Applications vCard WTA) Ч Этот набор дополнений (предназначенных для телефонии) обеспечивает v Card является открытой спецификацией, разработанной организацией Versit механизмы управления вызовом и функциональными возможностями, позволяя Consortium, одновременно с vCalendar. Ответственность за разработку и поддерж пользователям получать доступ и взаимодействовать с мобильными телефонами К У vCard сейчас возложена на консорциум почты Интернет (IMC). vCard исполь для приложений телефонная книга и календарь.

зуется в таких приложениях как Интернет почта, голосовая почта, Web-браузеры, WMLScript является упрощенным процедурным языком подготовки сценариев, Те лефония, центры обработки вызовов, видеоконференции, PIM, PDA, пэйджеры, основанным на JavaScript. WMLScript улучшает стандартные возможности про фисное оборудование и смарт-карты. Информация vCard не ограничивается про смотра и презентации WML с поведенческими характеристиками. Например, при стым текстом, и может включать такие элементы как картинки, логотипы компа кладной программист может использовать WMLScript для проверки достовернос ний и ссылки на Web-страницы.

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

vMessage и vNote Два других формата содержимого, которые передаются протоколом ОВЕХ, Ч это форматы vMessage (лсообщение) и vNote (лзаметка). Они также являются от крытыми стандартами и используются для обмена сообщениями и замечаниями.

Они определены в спецификации инфракрасной технологии для связи с подвиж ными объектами (IrMC). Там же определен формат журнальных файлов, который необходим для синхронизации данных между отдельными устройствами.

2.3.7. Резюме Рис. 2.52. Формат vCalendar Протоколы Bluetooth способствуют быстрому развитию различных приложений.

vCard содержит в себе важные справочные данные, такие как имя, адреса (рабочий, Нижние уровни стека протоколов разработаны с целью обеспечения гибкой осно домашний, электронный), телефонные номера (домашний, рабочий, мобильный), вы для дальнейшего развития протоколов. Другие протоколы, такие как факс, пэйджер, ISDN, голос, данные, видео, ссылки на Web-страницы (рис. 2.53). RFCOMM, заимствованы и незначительно модифицированы для Bluetooth. Про токолы высших уровней, такие как WAP, используются без изменений. Таким об разом, существующие приложения могут использоваться для работы с беспровод ной технологией Bluetooth, не препятствуя взаимодействию.

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

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

Рис. 2.53. Формат vCard Профили определяют специальные сообщения и процедуры, используемые для выполнения определенной функции. Функции могут быть обязательными, допол Все vCard могут также содержать графику и мультимедийные данные, включая нительными или условными. Одинаковые функции одинаково работают в любом фотографии, логотипы компании и аудио-клипы. Информация о географических и устройстве, вне зависимости от производителя.

временных зонах, представленная в vCard, позволяет определить время, когда Четыре общих профиля являются базовыми и применяются для различных мо можно звонить абоненту. vCard также поддерживает большое количество языков.

делей использования. Это профиль общего доступа, профиль последовательного Спецификация vCard является транспортно- и ОС- независимыми, таким обра- порта, профиль приложения обнаружения услуг и профиль общего обмена объек зом, пользователь может установить программное обеспечение для vCard на любом тами. Остальные профили применяются непосредственно для определенных моде компьютере. Разные программы хранят vCard по-разному. Некоторые позволяют лей использования [17, 18].

перетаскивать пиктограмму vCard в программы, другие требуют, чтобы vCard 2.4.1. Профиль общего доступа Профиль общего доступа (Generic Access Profile Ч GAP) определяет общие про цедуры для обнаружения устройств Bluetooth, а также процедуры управления свя зью между устройствами. Таким образом, главной целью этого профиля является описание использования нижних уровней стека протоколов Bluetooth Ч LC и LMP. В этом профиле также определены процедуры, связанные с секретностью, в которых начинают действовать высшие уровни Ч L2CAP, RFCOMM и ОВЕХ.

Профиль общего доступа описывает работу устройств, находящихся в режиме ожидания (Standby) и соединения (Connection). Это, в свою очередь, гарантирует, что между устройствами Bluetooth всегда могут быть установлены линии и каналы связи. Если устройства работают одновременно в соответствии с несколькими про филями, GAP описывает механизмы управления всеми ими.

Профиль общего доступа определяет общие процедуры для обнаружения имен, особенностей и основных возможностей устройств Bluetooth, которые поддаются обнаружению. Устройство, поддающееся обнаружению, готово установить соеди нение и принять запросы на обслуживание от других устройств. Даже если два уст ройства Bluetooth не имеют общего приложения, они должны быть способны свя заться друг с другом для определения своих возможностей. Если два устройства от Рис. 2.54. Связь профиля общего доступа с другими профилями Bluetooth разных производителей имеют общие приложения, установление соединения не будет затруднено только потому, что производители решили по-разному назвать канале L2CAP. Подразумевается, что соединение происходит по последовательно основные возможности Bluetooth па уровне пользовательского интерфейса, или му кабелю, который эмулируется с помощью этого профиля.

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

альный последовательный порт с передачей управляющих сигналов интерфейс с Устройства Bluetooth, которые не соответствуют какому-либо другому профи RS-232 вместо физического последовательного кабеля.

лю, должны по крайней мере соответствовать GAP. Это гарантирует их взаимодей При простой конфигурации последовательного порта, в которой два компьютера ствие и совместимость со всеми устройствами Bluetooth, независимо от того, какие соединены эмулированным последовательным кабелем (рис. 2.56), одно устройст- типы приложений они поддерживают. Устройства, которые соответствуют другому профилю Bluetooth, могут использовать адаптации общих процедур так, как это определено этим профилем. Однако они должны быть совместимы с GAP на уров не общих процедур. На рис. 2.54 изображена связь профиля общего доступа с дру гими профилями Bluetooth.

2.4.2. Профиль последовательного порта При использовании беспроводной технологии Bluetooth с целью замены кабеля, для получения канала, ориентированного на соединение, используется профиль последовательного порта (Serial Port Profile Ч SPP). Этот профиль основан на про филе общего доступа (GAP) и определяет то, как устройства Bluetooth могут быть настроены для эмулирования последовательного кабельного соединения с исполь зованием RFCOMM, транспортного протокола, который эмулирует последова тельный порт RS-232 между двумя равноправными устройствами (рис. 2.55).

RFCOMM используется для передачи пользовательских данных, модемных сигна лов управления и команд задания конфигурации. Сеанс RFCOMM происходит в Рис. 2.55. Модель эмуляции последовательного кабельного соединения ставления персонального идентификационного номера (PIN) для создания ключа связи, необходимого для авторизации устройства и кодирования данных. После ус тановления линии связи может потребоваться обнаружение BD_ADDR другого модуля Bluetooth посредством процедур запроса (inquiry) и вызова (paging).

Протокол обнаружения услуг, включенный в стек протоколов, используется для обнаружения услуг, которые могут предоставить устройства Bluetooth, на ходящиеся в зоне действия, а также услуг, доступных через эти устройства. По с ме создания линии связи, услуги могут быть обнаружены, и одна или несколько из них могут быть выбраны через интерфейс пользователя. Хотя протокол обна ружения услуг не непосредственно включен в организацию доступа к опреде Инициатор ленной услуге, он облегчает доступ путем привлечения локального стека Рис. 2.56. Два компьютера, один из которых выполняет роль инициатора, а другой роль Bluetooth для доступа к требуемой услуге. В отличие от других профилей, где получателя при установлении последовательного кабельного соединения обмен данными по обнаружению услуг происходит из-за необходимости переме во берет инициативу создания соединения с другим устройством. Такое устройство щать услугу, этот профиль требует, чтобы обнаружение услуг было затребовано называется инициатором, а другое получателем. Когда инициатор начинает уста- пользователем.

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

Согласно этому профилю, поддерживаются скорости передачи данных до 128 кбит/сек. Хотя технические требования Bluetooth описывают соединение двух устройств с помощью эмулированного последовательного порта в конфигурации point-to-point, ничто не препятствует многократному одновременному использова нию SPP на одном устройстве для создания нескольких соединений. В таких слу чаях устройства могут выступать даже в двух различных функциях (инициатора и получателя) одновременно. В этом профиле не определяется фиксированных ро лей мастер/подчиненное устройство, так как предполагается, что устройства рав ноправны.

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

2.4.3. Профиль приложения обнаружения услуг Профиль приложения обнаружения услуг (Service Discovery Application Profile SDAP) описывает процедуры и функции, используемые для обнаружения услуг, зарегистрированных на других устройствах Bluetooth, а также для получения ин формации об этих услугах. Стандартные процедуры помогают пользователям обна ружить и идентифицировать услуги, которые могут быть предоставлены устройст вами Bluetooth.

В этом профиле используются только каналы, ориентированные на соединение.

Кроме того, не используется широковещание L2CAP. До того как какие-либо два устройства Bluetooth смогут обмениваться информацией друг с другом, они долж Рис. 2.57. Стек протоколов Bluetooth для профиля приложения обнаружения услуг ны быть включены и инициализированы. Инициализация может требовать предо- 2.4.4. Профиль общего обмена объектами Профиль общего обмена объектами (Generic Object Exchange Profile Ч GOEP) оп ределяет модели использования обмена объектами, включая профиль передачи файлов, профиль помещения объекта в стек и профиль синхронизации. Самые рас пространенные устройства, которые используют эти модели, это ноутбуки, PDA, с март-телефоны и мобильные телефоны, использующие беспроводную технологию Bluetooth.

Профиль GOEP обеспечивает полное взаимодействие для прикладных профилей, использующих протокол ОВЕХ и определяет требования к взаимодействию нижних уровней стека протоколов (т.е. Baseband и LMP) для прикладных профилей.

Профиль GOEP определяет использование клиент-серверного протокола ОВЕХ, заимствованного у IrDA, который позволяет приложениям обмениваться данными непосредственно, без использования протокола IP.

Протокол ОВЕХ предоставляет услуги обмена объектами, подобно протоколу передачи гипертекстовых файлов (HTTP), который используется в сети Интернет.

Однако ОВЕХ работает для многих устройств, которые не могут предоставить не обходимые ресурсы, требуемые HTTP-сервером. Главное преимущество ОВЕХ за ключается в поддержке приложений Push запись в стек, и Pull записи из стека, что позволяет установить своевременную и эффективную связь между портатив ными устройствами в динамической среде.

ОВЕХ не ограничен быстрыми сценариями соединение-передача-разъедине ние. Возможны длительные сеансы связи, при которых соединение поддерживает ся даже когда в этом нет необходимости. Это значит, что ОВЕХ может использо ваться для выполнения сложных задач, таких как передача баз данных и синхрони- Рис. 2.58. Обычный сценарий обнаружения услуг, в котором компьютер посылает запросы услуг различным удаленным устройствам. Компьютер получит назад ответы на запросы услуг от SDP сервера одного или нескольких устройств Протокол SDP поддерживает запросы следующих услуг:

Х Поиск по классу услуги Х Поиск атрибутов услуг Х Просмотр услуг Первые два типа запросов используются при поиске определенных услуг и предоставлении пользователю ответов на следующие вопросы: Доступна ли ус луга X? или доступна ли услуга X с характеристиками 1 и 2? Просмотр услуг используется для поиска общих услуг и предоставляет пользователю ответы на следующие вопросы: Какие услуги доступны? или Какие услуги типа X до ступны? При совершении какого либо из этих запросов услуг необходимо, что бы устройства сначала были обнаружены, чтобы была установлена линия связи, и только потом запрашиваются услуги, которые поддерживаются этими устрой ствами.

Рис. 2.59. Протоколы и объекты, используемые в профиле общего обмена объектами зация. Он спроектирован для обеспечения межплатформенного взаимодействия.

Протокол ОВЕХ компактный, гибкий, открытый (наращиваемый), минимизирует нехватку ресурсов небольших устройств.

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

2.4.5. Профиль внутренней связи Профиль внутренней связи (InterCom Profile Ч ICP) поддерживает модели ис пользования, которые требуют прямой линии связи для передачи речи между устройствами Bluetooth, например, сотовыми телефонами. Даже при прямом ;

оединении телефонов (phone-to-phone) с использованием только беспровод-*ой технологи Bluetooth, линия связи должна быть установлена с использова- сигнализации, основанной на телефонии. Используемый голосовой кодек быть как импульсно-кодовой модуляцией (РСМ), так и дельта-модуля-щей с переменной крутизной (CVSD). Согласование качества услуг (QoS) необязательно.

Рис. 2.61. Блок-схема модели профиля внутренней связи Элемент управления вызовом (СС) использует интерфейс А для управления синхронизацией речи и для соединения и разъединения речевых каналов. Интер фейс В доставляет сообщения TCS на L2CAP канал, ориентированный на соедине ние (point-to-point). Интерфейс С используется элементом СС непосредственно для управления администратором связи с целью установления и разъединения SCO линий связи. Он также непосредственно управляет элементами LC/Baseband для введения режимов запроса, вызова, ожидания запроса и ожидания вызова.

'ис. 2.60. Профиль внутренней связи зависит от профиля общего доступа На рис. 2.62 изображена типичная конфигурация устройств, которые используют профиль внутренней связи. Так как модель использования внутренней связи На рис. 2.60 показана зависимость профиля внутренней связи от профиля обще-о полностью симметрична, в ней нет определенных ролей для каждого устройства.

доступа. В модели профиля внутренней связи, интерфейсы, помеченные на Устройства, поддерживающие профиль внутренней связи, как правило, относятся не. 2.61 буквами А, В и С, используются для следующих целей:

к терминалам (Terminal TL).

Сотовый телефон Сотовый телефон Рис. 2.62. Конфигурация системы двух устройств, использующих профиль внутренней связи Когда терминал осуществляет вызов другого терминала по внутренней связи (intercom call) имеют место несколько взаимодействий. Если инициатор вызова по внутренней связи не имеет Bluetooth-адреса получателя, он должен получить его, используя процедуру обнаружения устройства, которая описана в профиле GAP.

Профиль внутренней связи не подразумевает определенного режима защиты, по этому для создания защищенного соединения могут быть выполнены процедуры Рис. 2.63. Зависимость профиля беспроводной телефонии от профиля общего доступа аутентификации и кодирования, определенные в профиле общего доступа.

Линия и канал связи устанавливаются инициатором также согласно профилю общего доступа. Когда вызов по внутренней связи установлен, может осуществ- ким образом, интерфейс В используется для доставки всех сообщений TCS, кото ляться двусторонняя связь между пользователями терминалов, например для пере рые посылаются по SCO L2CAP каналу point-to-point. Интерфейс D используется дачи речи.

элементом СС для непосредственного управления администратором связи (LM) с 2.4.6. Профиль беспроводной телефонии Профиль беспроводной телефонии (Cordless Telephony Profile Ч СТР) определяет процедуры и функции, связанные с установлением вызова через базовую станцию и созданием прямых внутренних вызовов между двумя терминалами. Он также мо жет использоваться для доступа к дополнительным службам, предоставленным внешней коммутируемой телефонной сетью общего пользования. Этот режим ра боты позволяет сотовым телефонам использовать беспроводную технологию Bluetooth как однонаправленный канал передачи данных ближнего действия для доступа к службам PSTN через базовую станцию беспроводного телефона, который относится к устройствам, которые могут работать как шлюз к PSTN.

Для выполнения этих функций профиль беспроводной телефонии использует протокол Baseband, протокол управления связью, L2CAP, протокол обнаружения услуг и протокол управления телефонией. Как видно из рис. 2.63, профиль беспро водной телефонии зависит от профиля общего доступа.

В профиле беспроводной телефонии, интерфейсы, обозначенные на рис. 2. буквами A-G, используются для следующих целей:

Как и в профиле внутренней связи, элемент управления вызовом (СС) исполь зует интерфейс А для управления синхронизацией речи, для соединения и разъе Рис. 2.64. Типичная конфигурация системы шлюза и терминальных устройств по профилю динения внутренних речевых каналов. Интерфейс В используется шлюзом для от беспроводной телефонии правления, а терминалом Ч для приема широковещательных сообщений TCS. Та- целью установления и разъединения SCO линий связи. Интерфейс Е используется процедурами группового управления для управления функциями LM в процессе инициализации и для основных целей обработки. В профиле беспроводной теле фонии интерфейс F не используется. Интерфейс G используется процедурами группового управления для непосредственного управления LC/Baseband с целью введения режимов запроса, вызова, ожидания запроса и ожидания вызова.

2.4.7. Профиль гарнитуры Профиль гарнитуры (Headset Profile HP) определяет протоколы и процедуры для модели использования, называемой головной телефон, или гарнитура. Эта мо дель использования может быть реализована такими устройствами, как сотовые те лефоны и персональные компьютеры (рис. 2.67). Гарнитура может работать как ау дио интерфейс ввода/вывода устройства, который обеспечивает свободу передви жения пользователя при поддержании конфиденциальности вызова. Гарнитура мо жет посылать АТ-команды и получать ответ. Это позволяет владельцу гарнитуры отвечать на входящие вызовы и завершать их без физического манипулирования Аудио шлюз Гарнитура телефонной трубкой.

На рис. 2.65 показана зависимость профиля гарнитуры от профиля последова- Рис. 2.66. Протоколы и объекты, используемые в профиле гарнитуры тельного порта и профиля общего доступа. На рис. 2.66 показаны протоколы и объ екты, которые используются в профиле гарнитуры. Baseband соответствует физи System for Mobile communications GSM) TS 07.10 в технических требованиях ческому уровню модели взаимодействия открытых систем (Open System Bluetooth для эмуляции последовательного порта, a SDP Ч это протокол обнару Interconnection OSI), a LMP и L2CAP соответствуют канальному уровню. Прото жения услуг Bluetooth. Для всех этих протоколов/объектов, профиль последова кол RFCOMM является адаптацией глобальной системы мобильной связи (Global тельного порта является основным стандартом;

при этом выполняются все требо вания, определенные профилем последовательного порта, кроме тех, где профиль гарнитуры явно определяет отклонения.

Объект луправление гарнитурой (рис. 2.66) отвечает за передачу сигналов уп равления гарнитурой, и основан на АТ-командах. В этом профиле предполагается, что объект луправление гарнитурой имеет доступ к некоторым процедурам ниж- Рис. 2.65. Профиль гарнитуры зависит и от профиля последовательного порта и от профиля общего доступа Рис. 2.67. Модель использования профиля гарнитуры них уровней, таким как установление SCO линии связи. Уровень эмуляции аудио порта является объектом, который эмулирует аудио порт на сотовом телефоне и персональном компьютере, а аудио драйвер является программным драйвером в гарнитуре.

Устройства, определенные профилем гарнитуры могут выполнять две функции:

аудио шлюз и гарнитура. Аудио шлюз (Audio Gateway AG) является аудио шлюзом для ввода и вывода. Типичными устройствами, работающими как аудио шлюзы, являются сотовые телефоны и персональные компьютеры. Гарнитура работает как механизм удаленного ввода/вывода аудио-шлюза. Профиль гарнитуры требует, чтобы оба устройства поддерживали SCO линии связи.

2.4.8. Профиль коммутируемого выхода в сеть Профиль коммутируемого выхода в сеть (Dial-Up Networking Profile DUNP) опре деляет протоколы и процедуры, используемые устройствами, такие как модемы и сотовые телефоны, для реализации моделей использования мост в Интернет (рис. 2.68). Среди возможных сценариев для этой модели Ч использование сотово го телефона в качестве беспроводного модема для соединения компьютера с серве ром коммутируемого доступа в Интернет, или использование сотового телефона Рис. 2.69. Профиль коммутируемого выхода в сеть зависит от профиля последовательного порта или модема компьютером для приема данных.

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

Интернет Рис. 2.68. Модель использования профиля коммутируемого выхода в сеть, которая называется мост в Интернет На рис. 2.69 изображена зависимость профиля коммутируемого выхода в сеть от профиля последовательного порта и профиля общего доступа. На рис. 2.70 изобра жены протоколы и объекты, использующиеся в профиле коммутируемого выхода в сеть. Baseband соответствует физическому уровню модели OSI, LMP и L2CAP со ответствуют канальному уровню. Протокол RFCOMM является адаптацией гло Рис.2.70. Протоколы и объекты, используемые в профиле коммутируемого выхода в сеть бальной системы мобильной связи (GSM) TS 07.10 в технических требованиях Bluetooth, a SDP Ч это протокол обнаружения услуг Bluetooth. Коммутация и уп- Уровень эмуляции модема Ч это объект, эмулирующий модем, а драйвер моде ма Ч это программный драйвер в информационном терминале. Для всех этих про токолов/объектов, профиль последовательного порта является основным стандар том;

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

В профиле коммутируемого выхода в сеть для устройств определены две функ ции: шлюз и информационный терминал. Шлюзом (Gateway Ч GW) является уст ройство, которое обеспечивает доступ к сети общего пользования. Типичными уст ройствами, которые могут работать как шлюз, являются сотовые телефоны и моде мы. Информационный терминал (Data Terminal Ч DT) Ч это устройство, которое использует dial-up-услуги (услуги коммутации) шлюза. Типичными устройствами, которые работают как информационные терминалы, являются настольные ПК, но утбуки и PDA.

2.4.9. Профиль факса Рис. 2.72. Протоколы и объекты, использующиеся в профиле факса Профиль факса определяет протоколы и процедуры, необходимые для реализации модели использования, которая называется точки доступа к данным, глобальные стве беспроводного факс-модема для отправления и приема факсимильных сооб сети (Wide Area Network WAN). Сотовый телефон или модем, использующий щений. Как показано на рис. 2.71, профиль факса зависит от профиля последова беспроводную технологию Bluetooth, может использоваться компьютером в каче- тельного порта и профиля общего доступа.

На рис. 2.72 показаны протоколы и объекты, которые используются в профиле факса. Baseband соответствует физическому уровню модели OSI, a LMP и L2CAP соответствуют канальному уровню. RFCOMM является адаптацией глобальной системы мобильной связи (GSM) TS 07.10 в технических требованиях Bluetooth, a SDP Ч это протокол обнаружения услуг Bluetooth. Для всех этих протоколов/объ ектов, профиль последовательного порта является основным стандартом;

при этом выполняются все требования, определенные в профиле последовательного порта, кроме тех, где профиль факса явно определяет отклонения.

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

Две функции, определенные для устройств в профиле факса, такие же как и в профиле коммутируемого выхода в сеть. Шлюзом является устройство, которое предоставляет услуги факсимильной связи. Типичными устройствами, которые Рис. 2.71. Профиль факса зависит от профиля последовательного порта и профиля общего могут работать как шлюзы, являются сотовые телефоны и модемы. Информацион Доступа ный терминал Ч это устройство, которое использует услуги факсимильной связи Рис. 2.74. Профиль доступа к локальной сети зависит от профиля последовательного порта и профиля общего доступа шлюза. Типичными устройствами, которые работают как информационные терми налы являются ноутбуки, PDA и настольные ПК.

2.4.10. Профиль доступа к локальной сети Профиль доступа к локальной сети определяет процедуры, с помощью которых ус тройства Bluetooth могут получать доступ к услугам LAN, используя протокол point-to-point поверх RFCOMM, а также использовать одинаковые РРР-меха низмы для объединения в сеть двух устройств Bluetooth. В этой модели многочис ленные информационные терминалы используют точку доступа к LAN (LAN Access Point Ч LAP) для беспроводного подключения к локальной сети. Подклю чившись, информационные терминалы работают так, как если бы они были под ключены к локальной сети через коммутируемый выход в сеть и могут получать доступ ко всем услугам, предоставленным локальной сетью.

Протокол point-to-point является стандартом проблемной группы проектирова ния Интернета (IETF), который широко используется как средство доступа к сети.

Он предоставляет протоколы аутентификации, кодирования и сжатия данных. Хо Рис. 2.75. Протоколы и объекты, используемые в профиле доступа к локальной сети тя протокол point-to-point поддерживает различные сетевые протоколы (например, IP, IPX и другие), профиль доступа к локальной сети не требует использования ка Как показано на рис. 2.74, профиль доступа к локальной сети зависит и от про кого-либо определенного протокола. Профиль доступа к локальной сети определя филя последовательного порта и от профиля общего доступа.

ет, как протокол point-to-point используется для доступа к локальной сети для од На рис. 2.75 изображены протоколы и объекты, использующиеся в профиле до ного устройства Bluetooth, доступа к локальной сети для многочисленных уст ступа к локальной сети. Baseband соответствует физическому уровню модели OSI, ройств Bluetooth и беспроводной связи компьютеров через эмуляцию последова a LMP и L2CAP соответствуют канальному уровню. Протокол RFCOMM является тельного кабеля.

адаптацией глобальной системы мобильной связи (GSM) TS 07.10 в технических требованиях Bluetooth, a SDP Ч это протокол обнаружения услуг Bluetooth. В кальной сети с целью получения доступа к LAN. Этот профиль предполагает, что и этом профиле определен объект управления (Management Entity Ч ME), который точка доступа к LAN и информационный терминал оснащены беспроводной техно координирует процедуры в процессе инициализации, конфигурирования и управ- логией Bluetooth.

ления соединением. Организация сети по протоколу point-to-point позволяет отда вать/забирать IP пакеты в/из РРР уровня и выдавать их в локальную сеть. Необ- 2.4.11- Профиль передачи файлов ходимый для этого механизм не определен в профиле доступа к локальной сети, но Профиль передачи файлов поддерживает передачу информационных объектов такую функцию имеет сервер удаленного доступа (Remote Access Server Ч RAS). (data objects) от одного устройства Bluetooth к другому. К этим устройствам обыч В профиле доступа к локальной сети для устройств определены две функции: но относятся персональные компьютеры, смарт-телефоны или PDA. Типы инфор точка доступа к локальной сети и информационный терминал. Точка доступа к ло- мационных объектов обычно включают *.exl (файлы Microsoft Excel), *.ppt (файлы кальной сети предоставляет доступ к таким сетям как Ethernet4, Token Ring5 и Fibre PowerPoint), *.wav (аудио файлы), *.jpg, *.gif (файлы изображения) и *.doc (файлы Channel6. Точка доступа к локальной сети предоставляет услуги РРР сервера. Со- Microsoft Word). Модель использования передача файлов также дает возмож единение point-to-point происходит поверх протокола RFCOMM, который ис- ность просматривать содержимое папок, которые находятся на удаленном устрой пользуется для транспортировки РРР пакетов и управления РРР потоком данных. - стве. Возможно создание новых папок и удаление старых. Между устройствами Информационный терминал является устройством, которое использует услуги могут передаваться целые папки и директории.

точки доступа к локальной сети. Типичными устройствами, которые могут рабо- Как показано на рис. 2.77, профиль передачи файлов зависит и от профиля по тать как информационные терминалы, являются портативные компьютеры, ноут- следовательного порта и профиля общего доступа, но он использует профиль об буки, настольные персональные компьютеры и PDA. Информационный терминал щего обмена объектами как основной профиль для взаимодействия приложений.

является РРР клиентом. Он устанавливает РРР соединение с точкой доступа к ло- На рис. 2.78 изображены протоколы и объекты, используемые в профиле переда чи файлов. Baseband соответствует физическому уровню модели OSI, a LMP и L2CAP соответствуют канальному уровню. Протокол RFCOMM является адапта цией глобальной системы мобильной связи (GSM) TS 07.10 в технических требо ваниях Bluetooth, a SDP Ч это протокол обнаружения услуг Bluetooth. OBEX яв- Рис. 2.76. Модель использования профиля доступа к LAN Ethernet Ч стандарт организации локальных сетей, описанный в спецификациях IEEE и других организаций;

наиболее популярная реализация Ethernet Ч локальная сеть lOBaseT и 100BaseT.

Token Ring Ч (маркерное кольцо) спецификация локальной сети кольцевой топологии, в кото рой кадр управления (supervisory frame) называемый также маркером (token) последовательно передается от станции к соседней;

станция, которая хочет получить доступ к среде передачи, должна ждать получения кадра, и только после этого может начать передачу данных.

Fibre Channel Ч волоконнно-оптический канал (стандарт, интерфейс и архитектура рассредо точенного хранения данных с использованием высокоскоростных оптических каналов).

Рис. 2.77. Профиль передачи файлов зависит от профиля последовательного порта и профиля общего доступа, но использует профиль общего обмена объектами как основной профиль ляется Bluetooth-адаптацией протокола инфракрасного объектного обмена, стан дартизованного Ассоциацией передачи данных в инфракрасном диапазоне (IrDA).

В профиле передачи файлов для устройств определены две функции: клиент и сервер. Устройство-клиент инициирует отправку объектов на сервер и получение объектов от сервера (т.е. выполняет операции Push и Pull). Устройство-сервер яв ляется удаленным устройством, которое представляет собой сервер объектного об мена и дает возможность просмотра папок, используя ОВЕХ-формат записи папок.

Сервер поддерживает папки и файлы, предназначенные только для чтения (read only), что позволяет ограничивать удаление и создание папок и файлов.

Рис. 2.79. Модель использования профиля передачи файлом Клиент Сервер Рис. 2.78. Протоколы и объекты, используемые в профиле передачи файлов Рис. 2.80. Профиль помещения объекта в стек зависит от профиля последовательного порта Профиль поддерживает аутентификацию и кодирование на канальном уровне, а и профиля общего доступа, но использует профиль общего обмена объектами как основной также аутентификацию ОВЕХ. Профиль передачи файлов не гарантирует того, что профиль сервер или клиент введут режим поддающийся обнаружению или готов к со единению автоматически, даже если они способны сделать это. Для начала пере Профиль помещения объекта в стек позволяет устройству Bluetooth помещать дачи файла на стороне клиента обычно требуется вмешательство конечного поль объект в папку Входящие другого устройства Bluetooth. Объект может быть ви зователя.

зитной карточкой или текстовым сообщением. Устройство может также принять объект от другого устройства Bluetooth. Два устройства Bluetooth могут обмени 2.4.12. Профиль помещения объекта в стек ваться объектами друг с другом.

Профиль помещения объекта в стек (Object Push Profile OPP) определяет реализа Как показано на рис. 2.80, профиль помещения объекта в стек зависит и от про цию модели использования помещения объекта в стек между устройствами филя последовательного порта и от профиля общего доступа, но использует про Bluetooth. Профиль использует GOEP для взаимодействия протоколов, необходи филь общего обмена объектами как основной профиль для взаимодействия прото мых для приложений. К самым распространенным устройствам, которые использу колов, необходимых для приложений.

ют модель использования помещения объекта в стек, относятся ноутбуки, PDA и мобильные телефоны.

На рис. 2.81 изображены протоколы и объекты, используемые профилем поме щения объекта в стек. Baseband соответствует физическому уровню модели OSI, а LMP и L2CAP соответствуют канальному уровню. Протокол RFCOMM является адаптацией глобальной системы мобильной связи (GSM) TS 07.10 в технических требованиях Bluetooth, a SDP Ч это протокол обнаружения услуг Bluetooth. OBEX является адаптацией протокола инфракрасного объектного обмена, стандартизо ванного Ассоциацией передачи данных в инфракрасном диапазоне (IrDA).

Рис. 2.82. Профиль синхронизации зависит и от профиля последовательного порта и от профиля общего доступа, но использует профиль общего обмена объектами как основной профиль Push-клиент Push-сервер Рис. 2.81. Протоколы и объекты, используемые в профиле помещения объекта в стек В профиле помещения объекта в стек для устройств определены две функции:

РшЬсервер и Риэпклиент. Pushcepeep является устройством, которое предоставля ет сервер обмена объектами. РивИклиент является клиент-устройством, которое помещает объекты на PushcepBep и получает их от него.

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

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

сятся ноутбуки, PDA, мобильные телефоны. Эта модель обеспечивает синхрониза- Раздел ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ 3.1. Обзор технологии и архитектуры построения Bluetooth Рис. 2.84. Модель использования профиля синхронизации систем Технология Bluetooth задумывалась как технология, замещающая кабельное со На рис. 2.82 показано, что профиль синхронизации зависит и от профиля после единение всевозможных устройств передачи данных и голоса. По существу, она яв довательного порта, и от профиля общего доступа, но использует профиль общего ляется аналогией технологии беспроводных локальных сетей (WLAN). Ключевы обмена объектами как основной профиль для взаимодействия протоколов, необхо ми особенностями, учитываемыми при разработке технологии Bluetooth, являются димых для приложений.

[20]:

На рис. 2.83 представлены протоколы и объекты, используемые в профиле син Х надежность;

хронизации. Baseband соответствует физическому уровню модели OSI, a LMP и Х невысокая сложность реализации;

L2CAP соответствуют канальному уровню. Протокол RFCOMM является адапта Х низкое потребление;

цией глобальной системы мобильной связи (GSM) TS 07.10 в технических требо Х низкая цена;

ваниях Bluetooth, a SDP Ч это протокол обнаружения услуг Bluetooth. Протокол Х работа в условиях помеховой обстановки.

ОВЕХ является адаптацией протокола инфракрасного объектного обмена, стандар Широкое применение этой технологии связи и перечисленные выше особеннос тизованного Ассоциацией передачи данных в инфракрасном диапазоне (IrDA).

ти накладывают отпечаток при практической реализации устройств.

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

Х антенна;

ство IrMC-клиент является настольным или портативным компьютером. Однако, в Х приемопередатчик;

связи с тем, что устройство IrMC-клиент должно также обеспечивать прием ко манд инициализации для начала синхронизации, оно также может временно рабо- Х baseband-контроллер (контроллер связи) и микроконтроллер (MCU) для ис тать как сервер. Устройство IrMC-сервер представляет собой сервер обмена объек- полнения программного обеспечения LC;

тами. Обычно, это устройство является мобильным телефоном или PDA. Если уст Х управляющее устройство.

ройство IrMC-сервер позволяет начинать процесс синхронизации, оно также вре На рис. 3.1 представлена структура устройства Bluetooth.На данный момент су менно работает как клиент.

ществует несколько вариантов построения Bluetooth-чипов: некоторые производи В профиле синхронизации и IrMC-клиент, и IrMC-сервер могут инициировать ус- тели предлагают либо только Bluetooth baseband-микросхемы (в большинстве сво тановление линии и канала связи, потому что они могут временно выполнять функ- ем включающие микроконтроллер), либо только приемопередатчики. Другие про ции либо клиента, либо сервера, и таким образом, создавать физическую линию свя- изводители предлагают частично или полностью интегрированное в один чип ре зи между собой. Профиль синхронизации не гарантирует того, что сервер или клиент шение, которое включает baseband-контроллер, приемопередатчик, микроконтрол введут режим поддающийся обнаружению или готов к соединению автоматиче- лер и внешнюю или интегрированную flash-память. Обзор модулей Bluetooth от ски, даже если они способны сделать это. Это значит, что для начала синхронизации различных фирм изготовителей приведен в разделе 3.5.

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

Следует отметить, что при разработке аппаратного решения Bluetooth-системы, т.е. микросхемы или набора микросхем, включающих какое-либо микроконтрол- лерное ядро, необходима полноценная разработка программного обеспечения для этого ядра, либо применение распространенного микроконтроллерного ядра с воз можностью использования программного обеспечения, реализующего стек Bluetooth, от третьих фирм (чаще всего стек протоколов Bluetooth написан на ANSI и Java языках, и, поэтому, является платформонезависимым). Существуют Рис. 3.1. Различные функциональные блоки Bluetooth-устройства также решения, при которых функции baseband-контроллера и верхних уровней реализуются полностью программным способом на специализированном микро процессоре.

физический канал представляет собой псевдослучайную последовательность Также следует отметить, что на аппаратном уровне, т.е. на уровне chipset'oB, разде перестройки частоты по 79 или 23 радиоканалам, шириной 1 МГц. Последователь ления на базовое/клиентское оборудование не существует. Построение архитектуры ность перестройки частоты уникальна для каждой пикосети и определяется адре база/клиент осуществляется на более высоких уровнях программного обеспечения и сом и часами мастера. Мастер Ч это выделенное устройство в пикосети,), которое реализуется, как было показано в разделе 2, через соответствующий профиль.

управляет трафиком. Остальные устройства являются подчиненными. Временные Стек протоколов Bluetooth и их взаимодействие приведены на рис. 2.2 (раздел 2).

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

[15J.

Мастер и подчиненные устройства передают поочередно. Мастер должен начать Ключевыми являются уровни Radio, Baseband, LMP, L2CAP, SDP.

передачу и потом передавать только в четных слотах (начиная с нулевого), а под Уровень Bluetooth Radio является самым нижним. Он определяет требования к чиненные устройства только в нечетных.

приемопередатчику, которые подробно рассмотрены в разделе 2.

Baseband уровень является физическим уровнем технологии Bluetooth. Он уп равляет физическими каналами и соединениями, выполняет коррекцию ошибок, скремблирование, выбор частоты передачи и приема (формирование последова тельности перестройки частоты), шифрование. Baseband-уровень расположен над уровнем Bluetooth Radio в стеке Bluetooth. Baseband-протокол реализуется как контроллер связи, который взаимодействует с протоколом LMP для инициализа ции канала передачи данных и управления мощностью. Baseband-уровень также управляет синхронными и асинхронными соединениями, выполняет процедуру по иска устройств Bluetooth в радиусе действия и вхождения с ними в связь.

Схема построения Bluetooth-устройства приведена на рис. 3.1 [15].

Таблица 3. Группа протоколов Протоколы в стеке Корневые протоколы Radio, Baseband, LMP, L2CAP, SDP Протокол замены кабеля RFCOMM Протокол управления телефонией TCS Binary, АТ-команды Заимствованные протоколы PPP, UDP/TCP/IP, OBEX, WAP, vCard, vCal, IrMC, WAE Модуль Bluetooth применяет схему дуплексной передачи с временным разделе нием. Временное окно (слот) составляет 625 мксек. Обмен информацией между устройствами происходит посредством пакетов. Каждый пакет передается на своей частоте и может занимать 1, 3 или 5 временных слотов. Два и более (до 7) уст ройств образуют пикосеть, в которой все устройства синхронно изменяют частоту передачи и приема.

Рис. 3.2. Реализация нижних уровней протокола Bluetooth 3.3. Особенности построения модулей Bluetooth Спецификацией определен интерфейс хост-контроллера (HCI), который осу Как было сказано выше, современные решения построения чипов или набора мик ществляется посредством USB, RS-232, UART (и других) протоколов передачи росхем для Bluetooth подразделяются на два вида: радио и baseband интегрированы данных, между хост-процессором, на котором программно реализуются верхние на одном кристалле, или в виде двух микросхем (радио и baseband на разных крис уровни протокола Bluetooth, и аппаратным модулем (устройством, платой, чипом), на котором программно-аппаратным способом реализуются нижние уровни прото- таллах). Радиочипы для системы Bluetooth фирмы-разработчики проектируют, ис кола Bluetooth (рис. 3.2). ходя из дешевизны, малого потребления и малых габаритов микросхемы.

Для приемника очень популярной является архитектура построения квадратур Программно-аппаратное обеспечение HCI реализует HCI-команды для Bluetooth устройства посредством baseband-команд, LM-команд, регистров состоя- ного смесителя с квазинулевой промежуточной частотой (1Ч3 МГц) или с нулевой ния, контрольных регистров и регистров событий. промежуточной частотой. Это позволяет избежать применения внешних керамиче ских фильтров как на входе приемника, так и при фильтрации соседнего канала на 3.2. Архитектура аппаратного модуля промежуточной частоте. После квадратурных перемножителей производится Аппаратный модуль Bluetooth (рис.3.3) состоит из аналоговой части Ч Bluetooth фильтрация сигнала (в цифровом или аналоговом виде) и его демодуляция. Архи Radio, и цифровой части Ч хост-контроллера. Хост-контроллер содержит аппарат- тектура с нулевой ПЧ требует применения более линейных квадратурных пере ный блок цифровой обработки Ч baseband-контроллер (который еще называется множителей и схем компенсации смещения постоянной составляющей, что увели контроллером связи), процессорное ядро (CPU) и интерфейс передачи данных. чивает потребляемый ток. Архитектура с квазинулевой ПЧ лишена данных недо статков, но в тоже время имеет свои ограничения [21].

В передатчике используют архитектуру нескольких видов:

Х модуляция проводится на несущей частоте при использовании двух квадра турных перемножителей после цифрового формирования модулирующего инфор мационного сигнала;

Х модуляция проводится подачей информационного сигнала после гауссовского фильтра (аналогового или цифрового) на генератор управляемый напряжением (ГУН) петли фазовой автоподстройки частоты (ФАПЧ).

Рис. 3.3. Аппаратная архитектура Bluetooth Baseband чипы, как правило строятся на ARM-иодобных процессорных ядрах, взаимодействующих с периферийными интерфейсами посредством подсоединения к внутренней системной шине.

Верхние уровни Bluetooth Цель построения Bluetooth систем, определяемая рабочей группой Bluetooth Протокол L2CAP реализует передачу и преобразование данных от верхних уров SIG, Ч цена полностью интегрированного решения должна быть менее $5 [19]'.

ней к baseband-уровню. Информационная часть пакетов формируется только из данных, передаваемых от уровня L2CAP. Уровень L2CAP определен только для ACL-связи. 3.4. Элементная база BluetoothЩ (v1.1) фирмы Ericsson Краткие характеристики спецификации Bluetooth vl.l:

Протокол обнаружения услуг предназначен для поиска определенного класса Х Технология Bluetooth применяется для замены кабелей, организации беспро устройств, предоставляющих какую-либо услугу.

водных персональных сетей (WPAN), построения ретрансляторов для голосовых и Протокол RFCOMM является эмулятором последовательного порта и основан на спецификации ETSI 07.10. Он эмулирует сигналы RS-232 через baseband-уро- информационных каналов;

вень Bluetooth для предоставления услуги последовательного порта стандартным Х Bluetooth устройства работают в нелицензируемом ISM (2.4 Ч 2.5 ГГц) диапа протоколам передачи данных. зоне частот (рабочие каналы = 2.402 Ч 2.480 ГГц);

Протоколы TCS Binary и АТ-команды предназначены для использования в уст- Х Количество каналов = 79;

ройствах передачи голосовых данных и данных, передаваемых по голосовому кана- Х Ширина канала = 1 МГц;

лу (факс, модем). Протокол TCS Binary основан на рекомендации ITU-T Q.931 Х Рабочая частота в каждом из 79 каналов задается по методу FHSS TDD;

(применительно к симметричному каналу, Annex D в рекомендации Q.931). АТ-ко Х Длительность временного слота = 625 мксек;

манды основаны на рекомендации V.250 ITU-T и рекомендации ETSI 300 Х Битовая скорость в канале = 1 Мбит/сек;

(GSM 07.07).

Х Два режима работы в пикосети мастер-устройство и подчиненное устройство;

Х Возможность организации рассредоточенной сети scatternet (работа устройст цией Bluetooth vl.l с выходной мощностью передатчика равной 0 дБм (класс 2).

ва в нескольких пикосетях);

Модуль поддерживает все приложения спецификации Bluetooth. Ключевые Х Наличие асинхронных (ACL)- для передачи данных, и синхронных (SCO)- особенности модуля:

для передачи голоса, каналов;

Х Bluetooth vl.l сертифицирован;

Х 1, 3, 5-ти слотовые пакеты;

Х Организация связей с 7-ю подчиненными устройствами в пикосети по типу Х Поддержка энергосберегающих режимов работы: SNIFF, PARK, HOLD;

точка Ч многоточка;

Х Разделение устройств по излучаемой мощности на три класса:

Х Выходная мощность передатчика 0 дБм (класс 2);

Х класс 1 - от 1 мВт (0 дБм) до 100 мВт (20 дБм), Х Соответствие нормам FCC и ETSI;

Х класс 2 - от 0,25 мВт (-6 дБм) до 2,5 мВт (4 дБм), Х Наличие дополнительных интерфейсов для разных приложений;

Х класс 3 Ч до 1 мВт (0 дБм).

Х UART только для данных (HCI логический интерфейс);

Х РСМ только для голоса;

3.4.1. Модуль Bluetooth ROK 101 Х USB для голоса и данных (HCI логический интерфейс);

Х I2C интерфейс для управления внешними I2C устройствами;

Х Внутренний кварцевый резонатор;

Х HCI логический интерфейс (USB и UART интерфейсы).

Области применения:

Х Компьютеры и периферия;

Х Портативные устройства и аксессуары;

Х Беспроводные точки доступа.

Рис. 3.4. Внешний вид модуля Bluetooth ROK 101 Основные характеристики модуля:

Х Напряжение питания = 3.3 В;

Модуль Bluetooth ROK 101 007 (рис. 3.4) предназначен для встраивания беспро Х Частота кварцевого генератора =13 МГц;

водного интерфейса связи Bluetooth в различные электронные устройства [22].

Антенный выход:

Модуль состоит из 3-х основных составляющих - микросхемы baseband-контрол Х Выходное сопротивление - 50 Ом;

лера, микросхемы Flash памяти и микросхемы приемопередатчика (аналогичной Передатчик:

микросхеме в радиомодуле Ericsson РВА 313 01/3). Блок схема модуля представле Х Выходная мощность = -6 -н+4 дБм;

на на рис.3.5. ROK 101 007 работает в безлицензионном ISM диапазоне частот 2.4 Х Внеполосное излучение соответствует спецификации Bluetooth vl.l;

2.5 ГГц и поддерживает передачу данных и голоса. Соединение модуля с устройст Приемник (BER < 0.1%):

вом, в которое он встраивается, осуществляется посредством USB v2.0 или Х Чувствительность = -77 дБм;

UART/PCM интерфейсов. При подключении модуля к компьютеру через USB ин Х Максимальный уровень входного сигнала = 13 дБм;

терфейс, модуль подключается как USB ведомое устройство и, поэтому, не требует Х Внеполосное излучение:

ресурсов компьютера. ROK 101 007 сертифицирован в соответствии со специфика- 30 МГц - 1 ГГц = -74 дБм;

1 ГГц - 12.75 ГГц = -60 дБм;

Х Избирательность в соответствии со спецификацией Bluetooth vl.l:

30-1910 МГц = +13 дБм;

1910-2000 МГц =+9 дБм;

2000Ч2399 МГц = -27 дБм (минимальное значение);

2484-3000 МГц = -14 дБм;

3000-12750 МГц = -5 дБм;

Baseband-контроллер:

Х Процессор - ARM7 TDMIЩ;

Х Аппаратное Ericsson baseband ядро (ЕВС Ч Ericsson Bluetooth Core);

Рис. 3.5. Блок схема модуля Bluetooth ROK 101 Программное обеспечение модуля:

Х LC;

Х LM;

Х LMP;

Х HCI;

Х Поддержка 3-х и 5-ти слотовых пакетов;

Х Поддержка РСМ u-закона, РСМ А-закона и CVSD голосового кодирования;

Внешние интерфейсы модуля:

Х UART (стандарт 16С550);

Х USB v2.0 (полноскоростной режим Ч 12 Мбит/сек;

поддержка Wake_Up и Detach сигналов);

Х РСМ (поддержка линейного закона, ц-закона, А-закона);

Х 12С (управление интерфейсом через выделенные HCI команды).

3.4.2. Радио модуль РВА 313 Рис. 3.7. Архитектура радио модуля РВА 313 01/ Х Baseband-контроллер;

Х Миниатюрный LGA-корпус 11.8 х 11.8 х 1.6 мм;

Х Не требует внешнего экранирования;

Области применения:

Х Точки доступа;

Рис. 3.6. Внешний вид радио модуля РВА 313 01/ Х Компьютеры;

Х Портативные устройства и аксессуары;

СВЧ приемопередатчик РВА 313 02 (рис.3.6) предназначен для реализации фи Х Модемы;

зического уровня Bluetooth интерфейса в ISM диапазоне 2.4-2.5 ГГц. Применяет Архитектурные особенности модуля:

ся технология скачкообразной перестройки частоты (1600 скачков/сек) по 79 рабо Х Техника модуляции при разомкнутой петле синтезатора;

чим каналам (от 2.402 до 2.480 ГГц) с битовой скоростью 1 Мбит/сек, что соответ Х Малопотребляющий генератор 3.2 кГц для энергосберегающих режимов рабо ствует максимально допустимой ширине канала в ISM диапазоне. Используется ты Bluetooth;

частотная манипуляция с фильтрацией модулирующего сигнала фильтром с гаус Х Программная подстройка кварцевого генератора и генератора 3.2 кГц;

совской характеристикой - GFSK. Модуль РВА 313 02 построен на основе специа Основные характеристики модуля:

лизированной микросхемы (ASIC) приемопередатчика, выполненной по техноло Х Напряжение питания = 2.7 В;

гии BiCMOS. Антенный фильтр, приемный и передающий симметрирующие Х Потребляемый ток:

трансформаторы, переключатель и усилитель мощности интегрированы в радио Режим передачи = 50 мА;

модуль. Крепление модуля на поверхность платы осуществляется шариковыми вы Режим приема = 60 мА;

водами. Архитектура радио модуля представлена на рис. 3.7.

Антенный выход:

Ключевые особенности модуля:

Х Выходное сопротивление = 50 Ом;

Х Bluetooth v 1.1 сертифицирован;

Передатчик:

Х Выходная мощность передатчика 100 мВт;

Х Девиация частоты = 140-175 кГц;

Х Для построения функционально полного устройства дополнительно требует:

Х Дрейф несущей частоты при передаче пакетов:

- * Антенну;

1 слот: 25 кГц;

* Резонатор 10Ч20 МГц или источник опорного синхросигнала 10Ч20 МГц;

3 слота: 40 кГц;

РАЗДЕЛ 3 ПРАКТИЧЕСКАЯ НЬАЛИЗАЦИЯ 5 слотов: 40 кГц;

ром системы. Разнообразные стандартные внешние интерфейсы: USB, I2C, GPIO, Х Выходная мощность =+14 ++20 дБм;

PCM, UART, позволяют успешно применять РВМ 990 90/2 в стационарных и мо Х Внеполосное излучение соответствует спецификации Bluetooth vl.l;

бильных устройствах. Блок схема Baseband контроллера РВМ 990 90/2 представ Приемник (BER< 0.1%):

лена на рис. 3.9.

Х Чувствительность = -86 дБм;

В основе контроллера лежит принцип совмещения аппаратных и программных Х Максимальный уровень входного сигнала = +14 дБм;

средств, что позволяет создавать малогабаритные гибкие модульные системы для Х Внеполосное излучение:

реализации приложений Bluetooth.

2300 МГц Ч 3000 ГГц = -27 дБм (максимальное значение);

ARM7TDMI RISC процессорное ядро вместе с относящимся к нему блоками Х Избирательность (в соответствии со спецификацией Bluetooth vl.l):

ОЗУ, ПЗУ, системным контроллером, модулем интерфейса с внешней шиной и 30-880 МГц =+11 дБм внешней Flash памятью формируют процессорную часть, которая управляет режи 880-915 МГц =+11 дБм 915 мами работы контроллера и взаимодействием протоколов внутри Bluetooth стека.

1710 МГц = +11 дБм 1710- Режим работы РВМ 990 90/2 задается программированием управляющих регист МГц =+11 дБм 1785-1850 МГц ров. Имеется возможность выбора между необходимой производительностью, по =+11 дБм 1850-1980 МГц =+ требляемой мощностью и конфигурацией.

дБм 1980-2000 МГц =+11 дБм ЕВС (Bluetooth DSP-блок), является блоком аппаратной поддержки 2000-2100 МГц = 0 дБм 2100 ARM7TDMI RISC процессора. Здесь выполняются прямые и обратные задачи 2200 МГц = -10 дБм 2200- формирования пакетов: помехоустойчивое кодирование, скремблирование, форми МГц = -13 -27 дБм 2300- рование проверочного CRC поля, криптошифрование данных. Реализованные в МГц = -15 -27 дБм 3000- блоке алгоритмы соответствуют спецификации Bluetooth vl.l.

МГц = -5 дБм Управляющий интерфейс:

Х Последовательный (на базе JTAG), настройка модуля производится через ре гистры.

3.4.3. Bluetooth Baseband контроллер РВМ 990 90/ Рис. 3.8. Внешний вид Bluetooth Baseband контроллера РВМ 990 90/ Baseband контроллер РВМ 990 90/2 (рис. 3.8) основан на модульной архитектуре Ericsson Bluetooth Core (EBC) [22]. В качестве процессорного ядра применяется встроенный ARM7 TDMI RISC микропроцессор, взаимодействующий с ЕВС и пе риферийными интерфейсами, подсоединенными к внутренней системной шине АМВАЩ. Такая схема позволяет использовать контроллер как во встроенных при ложениях, так и в системах, где приложение выполняется центральным процессо- Рис. З.9. Блок схема Bluetooth Baseband контроллера РВМ 990 90/ Основные характеристики блока:

GPIO/I2C Х Поддержка скорости передачи информации до 721 кбит/сек в ACL канале;

РВМ 990 90 может задавать 10 выводов как универсальные входы Ч выходы.

Х Поддержка до трех одновременных голосовых SCO каналов;

Для этих целей используются 8 выводов старшего байта данных и 2 выделен Х Аппаратная поддержка пакетов всех типов;

ных вывода. Последние по включению питания сконфигурированы на 12С ин Х Поддержка одного последовательного синхронного РСМ канала;

терфейс. Функции всех выводов задаются программно. Максимальная скорость Х Низкая потребляемая мощность;

передачи информации поддерживаемая этим интерфейсом составляет Х Поддержка режимов HOLD, SNIFF, PARK;

100 кбит/сек.

Х Поддержка ключей криптозащиты размерностью до 128 разрядов;

РСМ Х Высококачественная фильтрация голосовых пакетов;

Входит в состав ЕВС блока. Обеспечивает передачу голоса. Может работать в Х Различные способы кодирования голосового сигнала (CVSD, РСМ А-закон, качестве ведущего или ведомого РСМ устройства. К функциям РСМ относятся:

РСМ ц-закон);

Х Синхронизация информационных потоков;

Х Организация пикосети с 7-ю подчиненными устройствами;

Х Переключение направления передачи для двунаправленных сигналов;

Х Возможность переключения режимов мастер и подчиненное устройство;

Х Преобразование из последовательного в параллельный коды;

Х BlueRF радиоинтерфейс;

Поддерживаемая скорость передачи информации от 200 кГц до 2 МГц в режиме ведомого и 2 МГц в режиме ведущего. Переменная разрядность передаваемых ин Подсистема памяти формационных символов 8 или 16 разрядов.

Х Размер встроенной памяти:

Статическое ОЗУ = 64 Кбайт;

Отладочный интерфейс JTAG ПЗУ = 4 Кбайт;

Использование отладочного интерфейса JTAG позволяет применить Multi-ICETM Х Возможность адресации от 2 до 16 Мбайт внешней Flash памяти.

и среду отладки ADS 1.1Щ фирмы ARM, Ltd.

Взаимодействие с центральной (host) системой Дополнительные характеристики контроллера:

Гибкость схемы контроллера предусматривает возможность использования его Внешняя частота синхронизации Ч задается из ряда 12.60, 12.80, 13.00, 14.40, 16.80, в системах с центральным процессором. Управление контроллером в этом слу 19.20 и 19.44 МГц;

чае осуществляется при помощи логического командного интерфейса HCI, по Напряжение питания:

средством предусмотренных для этих целей стандартных интерфейсов USB и внутренней части схемы = 2,8 В;

UART.

внешнего интерфейса = 3,3 В;

Корпус Ч 96 выводной BGA, 8 х 8 х 0,85 мм;

Интерфейсы контроллера USB Реализует версию стандарта USB 2.0, поддерживает передачу данных со скоро стью 12 Мбит/сек и имеет встроенные схемы драйверов.

UART1, UART В контроллере имеются два 16С550 совместимых порта UART1 и UART2.

UART1 имеет 128-байтовое FIFO и поддерживает работу модема в полной конфи гурации со скоростью до 921 кбит/сек. UART2 имеет 16 байтовое FIFO, две управ ляющие линии Тх и Rx, работает со скоростью до 230 кбит/сек и предназначен для управления схемой контроллера и начальной загрузки.

Интерфейс внешней шины Интерфейс внешней шины позволяет подключать до 3-х банков индивидуально на страиваемой Flash памяти, каждый размером до 1024 К.

Рис. 3.10. Пример системы с использованием Bluetooth Baseband контроллера РВМ 990 90/ ПКАМИЧЬ1ЖАЯ РЕАЛИЗАЦИЯ Встроенное программное обеспечение Таблица 3.2. Общие характеристики Встроенное программное обеспечение состоит из программ протоколов стека Без регулятора С регулятором Bluetooth и драйверов ЕВС, USB, UART, GPIO и 12С. В зависимости от уровня ин Напряжение VDD1 (1,8 0,1) В (3,3 0,1) В теграции, протоколы стека либо ограничиваются программами LM и HCI при ра питания VDD2 (2,8-3,4) В (3,3 0,1) В боте с центральной системой, либо включают протоколы стека в более полном объ VDD3 (1,7-3,4) В (3,3 0,1) В еме, необходимом для реализации встроенных приложений.

Ток потребления в спящем 20 мкА (кроме WML-C19AHN, который не имеет этого режиме режима) Температурный диапазон От -40'С до +85Т Частотный диапазон (2402-2480) МГц Модуляция GFSK, 1 Мбит/сек, ВТ-0, Максимальная скорость Асинхронный режим: 723,2 кбит/сек/57,6 кбит/сек передачи Синхронный режим: 433,9 кбит/сек/433,9 кбит/сек Выходная мощность 0 дБм (класс 2) Перестройка по частоте 1600 скачков в сек, ширина канала 1МГц Чувствительность -82дБм Генератор 16 МГц Рис. 3.11. Bluetooth-стек в системе с центральным процессором (уровни Baseband, LM, HCI) Хост-интерфейс Данные UART (BCSP или Н4) Голос РСМ-интерфейс UART Коэффициент усиления антенны 2.14 дБи Таблица 3.3. Характеристики передатчика Минимальное Типовое Максимальное Размерность значение значение значение -6 0 +4 дБм Выходная мощность Точность установки частоты -75 0 +75 кГц Уровни побочных излучений -36 дБм в режиме передачи сигнала -30 дБм дБм (30-1000) МГц: (1-12,75) - дБм ГГц: (1,8-1,9) ГГц: (5,15-5,3) - Рис. 3.12. Bluetooth-стек во встроенной системе ГГц:

Уровни побочных излучений в -57 дБм режиме отсутствия передачи -47 дБм 3.5. Bluetooth модули компании Mitsumi (передатчик выключен) (30 -47 дБм Одним из мировых лидеров по выпуску модулей Bluetooth для широкого спектра 1000) МГц: (1-12.75) ГГц:

-47 дБм приложений является компания Mitsumi ( Все модули со- (1.8-1.9) ГГц: (5.15-5.3) ГГц:

браны на чипсете BlueCore компании CSR ( Поставкой Bluetooth модулей WML-C19 и WML-C20 на российский рынок занимается хол 57 70 мА Потребление тока динг ПетроИнТрейд (

Серия WML-C Bluetooth HCI модули серии WML-C19 поддерживают второй класс выходной Тип интерфейса: В = BCSP (UART)/H = Н4 (UART) мощности и содержат встроенную 8Мбит флэш-память, приемопередатчик и base Регулятор напряжения 168 В: N = Нет/R = Есть WML-C19 N В N band-контроллер. В таблицах 3.2, 3.3 и 3.4 представлена краткая спецификация на Встроенная антенна TDK HAN8030B2R4GT-000:N = Нет/А - Есть модуль серии WML-C19.

Таблица 3.4. Характеристики приемника Таблица 3.6. Характеристики передатчика Минимальное Типовое Максимальное ЧЧ - Минимальное Типовое Максимальное Размерность Размерность значение значение значение значение значение значение Чувствительность -82 -72 дБм Выходная мощность 11 14 17 дБм Максимальный уровень -20 0 дБм Точность установки частоты -75 0 +75 кГц входного сигнала Уровни побочных излучений -36 дБм Избирательность -10 дБм в режиме передачи сигнала -30 дБм 30 МГц - 2000 МГц: 2000 -27 дБм дБм (30-1000) МГц: (1-12,75) - МГц - 2399 МГц: 2498 -27 дБм дБм ГГц: (1,8-1,9) ГГц: (5,15-5,3) - МГц - 3000 МГц: 3000 -10 дБм ГГц:

МГц - 12.75 ГГц:

Внеполосное излучение -57 дБм Уровни побочных излучений в -57 дБм 30 МГц - 1 ГГц: 1 ГГц- - дБм режиме отсутствия передачи -47 дБм 12.75 ГГц:

(передатчик выключен) (30- -47 дБм 1000) МГц: (1-12.75) ГГц:

-47 дБм Интермодуляционная -39 дБм (1.8-1.9) ГГц: (5.15-5.3) ГГц:

характеристика Потребление тока 54 70 мА Потребление тока 110 150 мА Серия WML-C WML-C20 N В Тип интерфейса: В = BCSP (UART)/H = Н4 (UART)/U = USB Встроенная Таблица 3.7. Характеристики приемника антенна TDK HAN8030B2R4GT-000: N = Нет/А = Есть Минимальное Типовое Максимальное Размерность значение значение значение Bluetooth HCI модули серии WML-C20 поддерживают первый класс выходной мощности и содержат встроенную 8Мбит флэш-память, приемопередатчик и base- Ч увствительность -80 -70 дБм Максимальный уровень -20 0 дБм band-контроллер. В таблицах 3.5, 3.6 и 3.7 представлена краткая спецификация на входного сигнала модуль серии WML-C20.

Избирательность 30 МГц -10 дБм - 2000 МГц: 2000 МГц - -27 дБм Таблица 3.5. Общие характеристики 2399 МГц: 2498 МГц - -27 дБм Напряжение питания (3,3 + 0,1) В 3000 МГц: 3000 МГц- -10 дБм 12.75 ГГц:

Ток потребления в спящем 100 мкА (кроме WML-C20AH, который не имеет этого Внеполосное излучение режиме режима) -57 дБм 30 МГц - 1 ГГц: 1 ГГц - -47 дБм Температурный диапазон От -40С до +70С 12.75 ГГц:

Частотный диапазон (2402-2480) МГц Интермодуляционная -39 дБм Модуляция GFSK, 1 Мбит/сек, ВТ=0. характеристика Максимальная скорост Асинхронный режим: 723,2 кбит/сек/57,6 кбит/сек ь Потребление тока 55 70 мА передачи Синхронный режим: 433,9 кбит/сек/433,9 кбит/сек Выходная мощность 14 дБм (класс 1) Перестройка но частоте 1600 скачков в сек, ширина канала 1МГц 3.6. Обзор модулей Bluetooth от различных фирм производителей Чувствительность -80дБм Ниже приведены данные о типах микросхем, их характеристиках и особенностях Генератор 16 МГц построения от различных фирм производителей [23, 24]. Приведенный материал Хост-интерфейс Данные UART (WML-C20AB, WML-C20AH)USB (WML-C20AU) характеризует особенности реализаций законченных модулей (таблица 3.8), кон Голос РСМ-интерфейс UART/USB троллеров Bluetooth (таблица 3.9) и Bluetooth приемопередатчиков (таблица 3.10), Коэффициент усиления антенны 2.14 дБп учитывая технологические возможности, традиции и опыт разработки этих фирм.

Таблица 3.8. Законченные модули Bluetooth (RF+Baseband контроллер) Фирма- Микросхема Характеристики Особенности изготовитель Х Чувствительность:

-82дБм;

Х внешним усилителем Bluetronics ICM101 Bluetooth v 1.1 сертифицирован;

Цифровая CMOS Выходная мощность: класс 2,3;

класса 1;

улучшенный Приемопередатчик технология;

Х Чувствительность:

-81дБм;

Контроллер Х USB (TR0760), микропроцессор 8051, специализированный Х Выходная мощность: класс 1 (+14дБм);

процессор;

собственная UART(TR0740) интерфейсы;

Х 4К ОЗУ, 64К Flash;

HCI логический интерфейс;

Х Park, встроенный голосовой Контроллер технология Bluetronics Х USB, UART, PCM интерфейсы;

Sniff, Hold режимы;

Х 3-х, 5-и кодек (TR0750);

JTAG EmbeddedRF;

Х HCI программный интерфейс;

интегрированная Х Park, Sniff, Hold, слотовые пакеты;

отладочный интерфейс;

Scatternet режимы;

антенна (0 дБи);

Broadcom BCM2033 Bluetooth vl.l возможность сертифицирован;

Fractional-N синтезатор;

Corporation встроенного приложения;

Приемопередатчик цифровая CMOS Х Чувствительность:

-80дБм;

технология;

управление Х Выходная мощность: класс 2,3;

внешним усилителем Bluetooth vl.l сертифицирован;

Управление внешним Microtune STw Контроллер класса 1;

Х USB, UART, PCM интерфейсы;

Приемопередатч 11 к Х усилителем класса 1;

(Transilica) специализированный Х НСI логический интерфейс;

процессор, 128К ОЗУ;

Х Park, Sniff, Чувствительность:

-78дБм;

Х ARM7TDMI процессор, Hold, Scatternet режимы;

Х 3 одновременных голосовых канала;

Х 3-х, 5-и слотовые пакеты;

С-Согл Выходная мощность: класс 2,3;

48К ОЗУ;

встроенный ВТМ-106А Bluetooth vl.l сертифицирован;

(класс 1) Приемопередатчик Контроллер Х UART, PCM, I2C, SPI Ericsson Bluetooth Core Flash-память 4 Мбит ВТМ-104 Х Чувствительность:

-80дБм;

или 8Мбит;

интерфейсы;

Х НСЛ логический (ЕВС) Link Controller;

встроенное (класс 2) Х Выходная мощность: класс 1,2;

ОЗУ;

встроенный Контроллер интерфейс;

Х Park, Sniff, Hold, JTAG отладочный регулятор напряжения Х USB, UART, PCM интерфейсы;

1.8В;

15-битный аудио Х Park, Sniff, Scatternet режимы;

Х 3 одновременных интерфейс;

Hold, Sleep, Scatternet режимы;

кодек (для ВТМ-106А);

Х 1, 3-х, 5-и слотовые пакеты;

BlueCore голосовых канала;

Х 3-х, 5-и слотовые возможность пакеты;

встроенного приложения;

Bluetooth vl.l сертифицирован Управление внешним (BlueCoreOl);

усилителем класса 1;

Приемопередатчик специализированный Х ST Micro- TC Bluetooth vl.l сертифицирован;

Цифровая CMOS (0. Чувствительность:-79дБм;

16-ти разрядный Х Выходная мощность: класс 2,3;

electronics Приемопередатчик Х мкм) технология;

процессор (BlueCoreOl), Контроллер 12К ОЗУ;

цифровая Х USB, Чувствительность:

-80дБм;

Х управление внешним UART, PCM интерфейсы;

CMOS технология Х HCI логический интерфейс;

Выходная мощность: класс 2,3;

усилителем класса 1;

(0.18 для BlueCore02);

Х Park, Sniff, Hold, Scatternet режимы;

возможность Х 3 одновременных Контроллер Х USB, UART ARM7TDMI процессор, голосовых канала;

встроенного приложения Х 3-х, 5-и слотовые пакеты;

интерфейсы;

Х HCI логический 64К ОЗУ, 128К Flash (BlueCore03);

Cambridge BlueBird Bluetooth 1.1 сертифицирован;

Цифровая интерфейс;

Х Park, Sniff, Hold, (TC2000P-4);

JTAG CMOS Silicon Приемопередатчик технология;

Radio Ч Scatternet (4 пикосети) режимы;

Х отладочный интерфейс;

CSR Х Чувствительность:

-ЭОдБм;

интегрированная Х Выходная 3-х, 5-и слотовые пакеты;

возможность встроенного приложения;

мощность: класс 1 (+20дБм);

керамическая антенна;

Контроллер 22К специализированный RAM + 512K SRAM;

Х UART, 1OM/PCM интерфейсы;

JTAG отладочный Х Park, Sniff, Zeevo Turbo скоростной Hold, Scatternet режимы;

интерфейс;

оптимизирован для голосовых приложений;

Inventel режим передачи данных TR07xx Bluetooth vl.l сертифицирован;

Цифровая CMOS Приемопередатчик (Bit Rate = х2, х4);

технология;

управление Bluetooth vl.l сертифицирован;

Цифровая CMOS Zeevo, Inc. PMB Приемопередатчик Х технология;

управление Чувствительность:

-85дБм;

Х внешним усилителем Выходная мощность: класс 2,3;

класса 1;

Контроллер Х UART, USB, интегрированный PCMCIA, PCM интерфейсы;

Х МШУ;

HCI логический интерфейс;

Таблица 3.9. Контроллеры Bluetooth Фирма Микросхема Характеристики Особенности изготовитель Atmel Bluetooth vl.l сертифицирован;

ARM7TDMI процессор, АТ76С Corporation USB, UART, PCMCIA интерфейсы;

64К ОЗУ;

встроенный HCI логический интерфейс;

голосовой кодек;

JTAG Scatternet режим;

отладочный интерфейс;

возможность встроенного приложения;

Signia PCF8775x Bluetooth vl.l сертифицирован ARM7TDMI процессор, BrightCom BIC2xxx Bluetooth vl.l сертифицирован;

ARC RISK процессор;

JTAG Technologies (до HCI);

64К ОЗУ, 384К Flash;

Technologies USB, UART, PCM, SPI, I2C, PCI отладочный интерфейс;

интерфейсы;

HCI логический USB, UART, PCM, I2C, SPI встроенный голосовой кодек встроенные приложения:

интерфейс;

интерфейсы;

(CVSD);

Philips Bluetooth LAN Access (BIC2301), Hi-Fi HCI логический интерфейс;

Core (PBC) Link Controller;

Audio (BIC2201);

Pages:     | 1 | 2 | 3 |    Книги, научные публикации