Достоинства беспроводной технологии Bluetooth основанные

Для устройств, выходная мощность которых превышает 0 дБм, необходима регулировка выходной мощности в диапазоне более 0 дБм. Регулировка выход­ной мощности в диапазоне менее 0 дБм опциональна и может использоваться

Побочные излучения
Побочные излучения внутри- и вне- рабочей полосы частот, измеряются при состо­янии передатчика, работающем на одной частоте (т. е. приемопередатчик перестра-


Рис. 2.4. Способ кодирования пакетной информации
ивает синтезатор поочередно между приемным и передающим слотом, но частота передачи всегда одинаковая). Нормы на излучение для США приведены в доку­менте FCC части 15.247, 15.249, 15.205, 15.209; для Японии в документе RCR STD-33; для Европы в рекомендации ETSI 328.


Побочные излучения внутри рабочей полосы частот
Внутри ISM полосы излучение передатчика должно соответствовать требованиям таблицы 2.5. Первое условие вытекает из требования FCC па 20 дБ полосу канала. Также FCC устанавливает требования на излучение на соседних рабочих каналах. Мощность излучения на соседнем канале определяется в полосе 1 МГц. Измере­ние мощности должно проводиться в полосе 100 кГц. М — канал передачи, N — со­седний канал. Передатчик должен передавать тестовую псевдослучайную последо­вательность (ПСП).
Таблица 2.5. Спектральная маска передаваемого сигнала

Отклонение частоты от несущей	Излучаемая мощность
±500 кГц	-20дБм
|М - N| - 2	-20 дБм
|М - N| > 3	-40дБм

Исключения по побочному излучению внутри рабочей полосы допустимы мак­симум на трех рабочих каналах (шириной по 1 МГц каждый), в то же время они должны удовлетворять требованию по абсолютному побочному излучению равно­му -20 дБм. Надо отметить, что это является требованием FCC.
Побочные излучения вне рабочей полосы частот
Измерение мощности должно проводиться в полосе 100 кГц.
В таблице 2.6 приведены уровни побочных излучений вне рабочей полосы.

Таблица 2.6. Уровни побочных излучении
Полоса частот	Режим передачи сигнала	Режим отсутствия передачи сигнала (передатчик выключен)
30 МГц - 1 ГГц	-36дБм	-57 дБм
1 ГГц - 12-75 ГГц	-30дБм	-47 дБм
18 ГГц- 1.9 ГГц	-47 дБм	-47дБм
5.15 ГГц-5.3 ГГц	-47 дБм	-47 дБм

Точность установки несущей частоты
Точность установки несущей частоты (определяется на момент начала передачи пакета) должна быть ±75 кГц от номинала FH. Следует учесть, что требование к ча­стотному дрейфу не включает вышеуказанные ±75 кГц. Допустимый дрейф несу­щей частоты во время передачи пакета определен в таблице 2.7.
Таблица 2.7. Допустимый дрейф несущей частоты

Тип пакета	Частотный дрейф
Однослотовый пакет	±25 кГц
Трсхслотовый пакет	±40 кГц
Пятислотовый пакет	±40 кГц
Максимальный дрейф несущей	400 Гц/мксек

Характеристики приемника
Для измерения вероятности появления ошибочных битов (Bit Error Rate — BER), устройство должно иметь режим обратной петли (loopback), т.е. устройство долж­но посылать обратно декодированную информацию. Базовый уровень чувстви­тельности при этом составляет -70 дБм.
Чувствительность приемника
Чувствительность приемника определена как уровень входного сигнала, для кото­рого BER на входе равен 0.1%. Требование к чувствительности для приемника Bluetooth: -70 дБм или лучше. Приемник должен соответствовать требованию чув­ствительности -70 дБм с любым передатчиком Bluetooth, удовлетворяющим тре­бованиям на передатчик системы Bluetooth.
Прием при наличии помеховых сигналов
Параметры приемника при помехе в соседнем канале, отстоящем на 1 МГц и на 2 МГц, измеряются при уровне принимаемого сигнала, превышающем базовый Уровень чувствительности на 10 дБ. Во всех остальных случаях уровень принимае­мого сигнала должен превышать базовый уровень чувствительности на 3 дБ. Если помеховый сигнал расположен вне рабочей полосы частот 2400—2497 МГц, то дан-

 

Данные требования тестируются только при номинальной температуре окружа­ющей среды, при этом, приемник «прыгает» на одной частоте (т.е. синтезатор пере­страивает частоту между передающим и приемным слотом, но при этом всегда воз­вращается на одну и ту же приемную частоту). Частоты помехи, при которых не выполняются требования таблицы 2.8 называются «помеховыми частотами». До- Таблица 2.10. Паразитное излучение приемника пускается пять помеховых частот, отстоящих на >2 МГц от сигнала приема. Для этих помеховых частот определены менее жесткие требования по соотношению сигнал/помеха: С/1 = -17 дБ.

ный случай следует рассматривать как прием при внеполосной помехе. Помеховы jj сигнал должен быть Bluetooth-модулированным при BER < 0.1% и соотношении сигнал/помеха, определеном в таблице 2.8.
Таблица 2.8. Прием при наличии помеховых сигналов

Требование	Соотношение
Помеха в соседнем канале, C/Ico.chany	ИдБ
Помеха в соседнем канале (1 МГц), С/1( мг	ОдБ
Помеха в соседнем канале (2 МГц), С/12 МГц	-30 дБ
Помеха в соседнем канале (>3 МГц), С/1>3 МГ|(	-40 дБ
Помеха зеркального канала C/Iimage	-9дБ
Помеха в канале, соседнем с зеркальным (1 МГц), C/Ijmagc+1 МГц	-20 дБ

Интермодуляционная характеристика приемного тракта
/ 1нтермодуляция приемного тракта определяется величиной BER = 0.1%, которая должна достигаться при следующих условиях:
» сигнал принимается на частоте f() с уровнем, на 6 дБ превышающем базовый уровень чувствительности;
•     смодулированная несущая передается на частоте 1, с уровнем -39 дБм;
•     Bluetooth-модулированный сигнал передается на частоте f2 с уровнем —39 дБм;
При этом f = 2f, - f2 и |2f, - f2| = n x 1 МГц, где п может принимать значения 3, 4,
или 5.
Динамический диапазон приемника
Максимальный уровень принимаемого сигнала должен быть лучше чем -20 дБм. При этом BER должен быть меньше или равен 0.1%.
Паразитное излучение приемника
Требования на паразитное излучение приемника приведены в таблице 2.10. Мощность излучения измеряется в полосе 100 кГц

Полоса частот	Мощность излучения
30 МГц - 1 ГГц	-57 дБм
1 ГГц - 12.75 ГГц	-47 дБм

Прием при помеховом сигнале вне рабочей полосы частот
Параметры приема при внеполосной помехе измеряются при уровне входного сиг­нала, превышающем уровень чувствительности на 3 дБ. BER не должен превышать 0.1%, а помеховый сигнал является немодулированной несущей, мощность которой определена в таблице 2.9.
Таблица 2.9. Параметры внеполосного помехового сигнала

Частота помехового сигнала	Мощность помехи
30 МГц - 2000 МГц	-ЮдБм
2000 МГц-2399 МГц	-27дБм
2498 МГц - 3000 МГц	-27дБм
3000 МГц - 12.75 ГГц	-ЮдБм

Допускаются 24 рабочие частоты (канала) с параметрами, отличающимися от вышеуказанных. При приеме на 19 из этих «помеховых» частотах допускается уро­вень внеполосной помехи -50 дБм для BER = 0.1%. На оставшихся 5 «помеховых» частотах уровень внеполосной помехи допускается произвольным.

Измеритель уровня принимаемого сигнала (опционально)
Если устройство должно управлять мощностью, передаваемой в канале, то приемни­ку необходимо измерять мощность принимаемого сигнала и принимать решение об увеличении или уменьшении мощности передаваемого сигнала на передатчике дру­гого устройства, входящего в канал связи.


Эта процедура возлагается на RSSI-блок. RSSI- блок измеряет уровень принимаемого сигнала и сравнивает его с двумя порога­ми, которые определяют диапазон принимаемой мощности, называемый «Golden Receive Power Range». Нижний порог соответствует диапазону уровней входного сигнала от -56 дБм до уровня, превышающего на 6 дБ реальный уровень чувстви­тельности приемника. Верхний порог на 20 ± 6 дБ выше нижнего порога (рис. 2.5).
Параметры Bluetooth-модулированного сигнала

GFSK
0.32 + 1%
0.5 ± 1%
1 Мбит/сек ± 1 ррт
не хуже ±1 ррт.

Модуляция                                                     -
Индекс модуляции
ВТ
Битовая скорость                                          -
очность установки несущей частоты


Рис. 2.5. Динамический диапазон и точность RSSI-блока
Параметры тестирования
Параметры тестирования описаны в приложениях к разделу Радио. Однако в этих приложениях нет процедуры для полного тестирования приемопередатчика. Фак­тически в приложениях приведены требования к рабочей температуре и напряже­нию.
Для получения логотипа Bluetooth необходимо официальное тестирование изде­лия на соответствие техническим требованиям.
2.2.2. Baseband
Это один из самых больших и наиболее сложных разделов технических требова­ний. В разделе Baseband рассматриваются вопросы организации и работы пикосе-ти.
Раздел Baseband состоит из 14 подразделов:
1)     Общее описание Baseband
2)  Физический канал
3)  Физические линии связи
4)  Пакеты
5)  Коррекция ошибок
6)  Логические каналы
7)  Обеливание данных
8)  Процедуры передачи/приема
9)  Синхронизация передачи/приема
10) Управление каналом
11)     Выбор перестройки частоты
12)     Аудио интерфейс
13)     Адресация устройств
14)     Защита
Общее описание
В общем описании Baseband рассмотрены вопросы организации пикосетей и тех­нологии Bluetooth в целом.


Оно представляет Bluetooth как радио линию (radio link) ближнего действия, предназначенную для замены кабельных соединений между портативными и/или стационарными электронными устройствами.

В стандарте Bluetooth предусмотрена дуплексная передача с временным разде-
ением (Time Division Duplex - TDD). Мастер передает пакеты в нечетные слоты,
' подчиненное устройство - в четные (рис. 2.7). Пакеты, в зависимости от длины,
огут занимать до пяти слотов. При этом частота канала не меняется до окончания
передачи пакета (рис. 2.8).
Пикосеть Bluetooth является сетью, которая образована мастером («главным» устройством) и одним или более подчиненными устройствами. Устройство, ини­циировавшее связь автоматически становится мастером пикосети. Каждая пико­сеть определена последовательностью скачкообразной перестройки частоты, кото­рая становится физическим каналом, основанным на адресе и часах станции масте­ра Все активные модули, входящие в эту пикосеть, синхронизированы к этому ка­налу В пикосети могут быть активными максимум семь подчиненных устройств.
В каждой пикосети действует только один мастер, однако подчиненные устрой­ства могут входить в различные пикосети. Кроме того, мастер одной пикосети мо­жет одновременно являться подчиненным устройством в другой (рис. 2.6, с). Пико­сети не синхронизированы друг с другом по времени и частоте - каждая из них ис­пользует свою последовательность перестройки частоты. В одной пикосети все уст­ройства синхронизированы по времени и частотам. Последовательность перест­ройки частоты является уникальной для каждой пикосети. Длина цикла псевдо­случайной последовательности перестройки частоты равна 227 элементов.

ис- 2.6. Возможные топологии пикосети Bluetooth

Технология Bluetooth предназначена для создания соединений point-to-point (когда в пикосеть включены только два элемента). Соединение point-to-multi­point - это разновидность модели с одним подчиненным устройством.


Для подчи­ ненного устройства не имеет значения, со сколькими еще устройствами связывается мастер. Разнесенная сеть (scatternet) формируется путем объединения одной или более пикосетей. Различные топологии пикосети Bluetooth изображены на рис. 2.6.

Физический канал
Физический канал представляет собой псевдослучайную последовательность пере­стройки частоты по 79 или 23 радиочастотным каналам шириной 1 МГц. Каждый канал делится на слоты продолжительностью 625 мксек, причем каждому слоту со­ответствует определенный канал. Слоты пронумерованы в соответствии с часами мастера пикосети, номера расположены в диапазоне от 0 до 227 -1. Передатчик в каждый момент времени использует только один канал. Перестройка частоты про­исходит синхронно на передатчике и на приемнике по закону заранее зафиксиро­ванной псевдослучайной последовательности. В секунду может происходить до 1600 перестроек частоты. Этот метод обеспечивает конфиденциальность и помехо­защищенность передач. Если на каком-либо канале передаваемый пакет не был принят, то приемник посылает запрос на повторную передачу и пакет повторно пе­редается на другом канале на другой частоте.

Рис. 2.8. Передача многослотовых пакетов

Следует учесть, что физическим каналом (physical channel) является набор ра­диочастот, распределенный по закону псевдослучайной последовательности, а фи­зической линией связи (physical link) является то, ЧТО ПЕРЕДАЕТСЯ по этому каналу на основе потоков данных.

Протокол Bluetooth может поддерживать асинхронный канал передачи данных, о трех синхронных (с постоянной скоростью) голосовых каналов или канал с од­новременной асинхронной передачей данных и синхронной передачей голоса. Ско­рость каждого голосового канала — 64 кбит/сек в каждом направлении, асинхрон­ного в асимметричном режиме — до 723,2 кбит/сек в прямом, и 57,6 кбит/сек в об­ратном направлениях или до 433,9 кбит/сек в каждом направлении в симметрич­ном режиме.
Физические линии связи


В этом разделе описаны два типа связи, которые могут быть установлены между мастером и подчиненными устройствами. Это два вида физических линий связи, каждая со своими Baseband-пакетами:
•     Синхронная ориентированная на соединение (SCO) линия связи — это симме­
тричная линия связи point-to-point между мастером и определенным подчиненным
устройством. SCO линия связи резервирует слоты, и таким образом, может рассма­
триваться как соединение с коммутацией каналов. SCO линии связи обычно под­
держивают передачу срочной информации, такой как голос. Мастер может поддер­
живать до трех SCO линий связи к одному или разным подчиненным устройствам.
Подчиненное устройство может поддерживать до трех SCO линий связи от одного
мастера или две линии связи, если они исходят от различных мастеров. SCO паке­
ты никогда не передаются повторно.
•     Асинхронная линия связи без установления соединения (ACL) используется
только для данных, и работает по принципу когда-позволяет-время. ACL линии
связи обеспечивают соединение с коммутацией пакетов между мастером и всеми
активными подчиненными устройствами пикосети. Поддерживаются как асин­
хронная, так и изохронная передача. Между мастером и подчиненным устройством
может существовать только одна ACL линия связи. Для большинства ACL пакетов,
повторная передача используется для обеспечения целостности данных.
Пакеты
Технические требования Bluetooth определяют использование двух видов паке­тов: синхронных ориентированных на соединение и асинхронных без установле­ния соединения. SCO-пакеты используются в синхронных каналах связи для пе­редачи голоса и направляются на синхронный I/O (input/output) голосовой порт. Они не содержат механизма обнаружения ошибок и никогда не передаются по­вторно, потому что это создает временные задержки, которые ухудшают качество голоса.
ACL-пакеты используются в асинхронных каналах связи. Передаваемая инфор­мация может быть пользовательскими данными или управляющей информацией.


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


Общий формат пакетов (рис.2.9), использующийся в беспроводной технологии Bluetooth состоит из трех частей: код доступа, заголовок и полезная информация.
Рис. 2.9. Общий формат пакетов
Код доступа
Каждый пакет начинается с кода доступа, который используется для оповещения и обмена служебной информацией. Поле кода доступа состоит из преамбулы, синх-рослова и концевика (рис. 2.10). Преамбула указывает на прибытие пакета в при­емник. Синхрослово используется для временной синхронизации с приемником. Концевик следует после синхрослова и указывает на окончание кода доступа. Ко­личество бит в коде доступа может варьировать, в зависимости от того, последовал ли заголовок пакета. Если заголовок пакета последовал, длина кода доступа состав­ляет 72 бита; в противном случае, 68 бит.

Функции кода доступа могут отличаться в зависимости от режима работы уст­ройства Bluetooth. Соответственно, существует три типа кода доступа:
• Канальный код доступа (Channel Access Code — САС) — распознает пикосеть. Этот код включен во все пакеты, которыми обмениваются по каналам пикосети. Все пакеты, посылаемые в одной пикосети, начинаются с одного канального кода доступа.

•    Код доступа устройства (Device Access Code — DAC) — используется для спе-
иальных процедур сигнализации, таких как вызов и ответ на вызов. Вызов вклю-
, ает в себя передачу ряда сообщений с установлением канала связи с модулем, ак­тивным в пределах зоны действия. Когда модуль отвечает на запрос, канал связи может быть установлен.
. Код доступа запроса (Inquiry Access Code — IAC). Существует два типа кода доступа запроса: общий и специализированный. Общий код доступа запроса оди­наков для всех устройств. Он используется для обнаружения других модулей Bluetooth, находящихся в зоне действия.


Специализированный IAC является оди­ наковым для отдельной группы модулей Bluetooth, которые имеют общие характе­ристики. Он используется для обнаружения только тех специализированных моду­лей Bluetooth, которые находятся в пределах зоны действия.
Заголовок
Если используется заголовок, то он содержит информацию управления каналом связи и состоит из шести полей, составляющих 18 бит (рис. 2.11).
•    Адрес активного члена (Active Member Address — АМА) (3 бита)
•    Тип (4 бита)
•    Поток (1 бит)
•     Автоматический запрос на повторение (Automatic Repeat Request — ARR)
(1 бит)
•     Порядковый номер (Sequence Number — SEQN) (1 бит)
•     Проверка заголовка на наличие ошибок (Header Error Check — НЕС) (8 бит)
Рис. 2.11. Поле заголовка
Адрес активного члена
Это 3-битное поле используется для различия между активными устройствами, принимающими участие в пикосети. В пикосети одно или более подчиненных уст­ройств связаны с одним мастером. Для того чтобы идентифицировать каждое под­чиненное устройство в отдельности, каждому подчиненному устройству назначает-

Общий формат пакетов (рис.2.9), использующийся в беспроводной технологии Bluetooth состоит из трех частей: код доступа, заголовок и полезная информация.

Код доступа
Каждый пакет начинается с кода доступа, который используется для оповещения и обмена служебной информацией. Поле кода доступа состоит из преамбулы, синх-рослова и концевика (рис. 2.10). Преамбула указывает на прибытие пакета в при­емник. Синхрослово используется для временной синхронизации с приемником. Концевик следует после синхрослова и указывает на окончание кода доступа. Ко­личество бит в коде доступа может варьировать, в зависимости от того, последовал ли заголовок пакета. Если заголовок пакета последовал, длина кода доступа состав­ляет 72 бита; в противном случае, 68 бит.

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


Соответственно, существует три типа кода доступа:
• Канальный код доступа (Channel Access Code — САС) — распознает пикосеть. Этот код включен во все пакеты, которыми обмениваются по каналам пикосети. Все пакеты, посылаемые в одной пикосети, начинаются с одного канального кода доступа.

•    Код доступа устройства (Device Access Code — DAC) — используется для спе-
иальных процедур сигнализации, таких как вызов и ответ на вызов. Вызов вклю-
еТ в себя передачу ряда сообщений с установлением канала связи с модулем, ак-(вным в пределах зоны действия. Когда модуль отвечает на запрос, канал связи жет быть установлен.
•    Код доступа запроса (Inquiry Access Code — IAC). Существует два типа кода
доступа запроса: общий и специализированный. Общий код доступа запроса оди­
наков для всех устройств. Он используется для обнаружения других модулей
Bluetooth, находящихся в зоне действия. Специализированный IAC является оди­
наковым для отдельной группы модулей Bluetooth, которые имеют общие характе­
ристики. Он используется для обнаружения только тех специализированных моду-
icii Bluetooth, которые находятся в пределах зоны действия.
Заголовок
Если используется заголовок, то он содержит информацию управления каналом связи и состоит из шести полей, составляющих 18 бит (рис. 2.11).
•    Адрес активного члена (Active Member Address — АМА) (3 бита)
•    Тип (4 бита)
•    Поток (1 бит)
•    Автоматический запрос на повторение (Automatic Repeat Request — ARR)
(1бит)
•    Порядковый номер (Sequence Number — SEQN) (1 бит)
•    Проверка заголовка на наличие ошибок (Header Error Check — НЕС) (8 бит)

Рис. 2.11. Поле заголовка
Адрес активного члена
Это 3-битное поле используется для различия между активными устройствами, Принимающими участие в пикосети. В пикосети одно или более подчиненных уст­ройств связаны с одним мастером. Для того чтобы идентифицировать каждое под­чиненное устройство в отдельности, каждому подчиненному устройству назначает-



ся временный 3- х битный адрес, который используется, когда устройство активно Пакеты, которыми обмениваются мастер и подчиненное устройство, имеют АМд этого подчиненного устройства. Другими словами, адрес подчиненного устройства используется как в пакетах, которые передаются от мастера к подчиненному уст­ройству, так и наоборот. Нулевой адрес зарезервирован для радиовещательных па­кетов от мастера к подчиненным устройствам. Прекращающие связь или находя­щиеся в режиме парковки (Park) подчиненные устройства оставляют свои адреса, а когда они снова войдут в пикосеть, им должен быть назначен новый адрес.
Тип
Это 4-битное поле используется для кода, который устанавливает тип пакета. Ин­терпретация этого кода зависит от типа канала, который ставится в соответствие пакету: либо SCO, либо ACL. Существует четыре различных типа SCO пакетов и семь типов ACL пакетов. Код типа также означает номер слотов, которые будет за­нимать текущий пакет. Это позволяет неадресованным приемникам воздерживать­ся от прослушивания канала в течение длительности оставшихся слотов.
Поток
Это 1-битное поле используется для управления потоком пакетов по ACL каналу. Когда буфер приемника для ACL каналов переполнен, возвращается указание «стоп» для временной остановки передачи данных. Сигнал «стоп» применяется только для ACL пакетов. Кроме того, могут быть приняты пакеты, включающие только информацию по управлению каналом связи, или SCO пакеты. Когда буфер приемника пуст, возвращается указание «старт». Когда не получено ни одного па­кета или полученный заголовок содержит ошибки, следует указание «старт».
Автоматический запрос на повторение
Это 1-битное поле используется для информирования передающего устройства об успешной передаче полезной информации. Благоприятный исход приема проверя­ется с помощью циклического избыточного кода (Cyclic Redundancy Code — CRC). Возвратное сообщение может быть в форме положительного уведомления (ACKnowledgement — АСК) или отрицательного уведомления (Negative Acknowledgement — NAK).


Если полезная информация была получена без искаже­ний, возвращается АСК, в противном случае — NAK. Когда не принимается ника­кого возвратного сообщения, предполагается получение NAK. ACK/NAK распола­гается в заголовке возвратного пакета.
CRC — это вычислительная процедура для обеспечения точности получаемых данных. Математическая функция вычисляется до передачи пакета на исходящем устройстве. Ее численное значение вычисляется на основе содержания пакета. Это значение сравнивается с пересчитанным значением функции в устройстве назначе­ния (адресате информации). Если эти два значения совпадают, возвращается АСК. в противном случае — NAK.

Порядковый номер
Ято 1-битное поле обеспечивает последовательную схему нумерации для того, что­бы правильным образом упорядочить поток пакетов данных, когда он достигает принимающего устройства. Для каждого нового переданного пакета, который со­держит данные со значением CRC, бит порядкового номера преобразуется для то­го, чтобы отфильтровывать повторные передачи на принимающем устройстве. Ес­ли повторная передача происходит вследствие отсутствия АСК, адресат принимает лот пакет дважды. Сравнение порядковых номеров следующих пакетов означает, что безошибочно принятые повторные передачи могут быть отброшены.
Проверка заголовка на наличие ошибок
Это 8-битное поле используется для проверки целостности заголовка. После ини­циализации генератора НЕС, вычисляется значение НЕС для битов заголовка. Приемник инициализирует свои схемы НЕС так, что он может интерпретировать значение. Если значения НЕС не совпадают, весь пакет игнорируется.
Полезная информация
Заключительной частью общего формата пакета является полезная информация. В этой части есть два типа полей: поле голоса (синхронное) и поле данных (асин­хронное). ACL пакеты имеют только поле данных, a SCO пакеты — только поле го­лоса. Исключением является пакет данных и голоса (Data Voice — DV), который имеет оба поля. Поле данных состоит из трех сегментов: заголовок полезной ин­формации, тело полезной информации и возможно, CRC код (рис. 2.12).



Ис- 2.12. Поле полезной информации
аголовок полезной информации
° лько поля данных имеют заголовок полезной информации. Длина заголовка по-езной информации равна одному или двум байтам и определяет логический канал

(Logical Channel — LCH), управление потоком в логических каналах, а также име­ет указатель длины полезной информации. Этот указатель обозначает количество байт (т.е. 8-битное слово) в теле полезной информации, исключая заголовок полез­ной информации и CRC код.
Тело полезной информации
Тело полезной информации включает пользовательскую информацию. Длина это­го сегмента указана в поле длины заголовка полезной информации.
Формирование CRC кода
После того как генератор CRC инициализирован, от передаваемой информации вычисляется 16-битный CRC код, который прикрепляется к информации.
Типы пакетов
В технических требованиях описаны также различные типы пакетов: общие, SCO-пакеты и ACL-пакеты. Каждому типу соответствуют определенные характе­ристики.
Общие пакеты:'
•     ID-пакет
•     Null-пакет
•     Poll-пакет
•     FHS-пакет
•     DM 1-пакет
SCO-пакеты:
•     HV1 -пакет
•     НУ2-пакет
•     НУЗ-пакет
•     DV-пакет
ACL-пакеты:
•     DM 1-пакет
•     DH1-пакет
•     ОМЗ-пакет
•     ОНЗ-пакет
•     ОМ5-пакет
•     DI-15-пакет
•     AUX1-пакет
В таблице 2.11 приведены используемые сокращения.
Коррекция ошибок
Как ACL-пакеты (данные), так и SCO-пакеты (голос и данные) могут быть снабже­ны различными уровнями прямой коррекции ошибок (Forward Error Correction — FEC) или проверки циклическим избыточным кодом (CRC), а также могут быть

Таблица 2.11
ID	Identification	Идентификация
NULL	Null	Пусто
POLL	Polling	(Упорядоченный)опрос
FHS	Frequency Hopping Synchronization	Синхронизация перестройки частоты
DM1	Data Medium rate, 1 slot	Средняя скорость передачи данных, один слот
Dili	Data High rate, 1 slot	Высокая скорость передачи данных, один слот
DM3	Data Medium rate, 3 slots	Средняя скорость передачи данных, три слота
DH3	Data High rate, 3 slots	Высокая скорость передачи данных, три слота
DM5	Data Medium rate, 5 slots	Средняя скорость передачи данных, пять слотов
DH5	Data High rate, 5 slots	Высокая скорость передачи данных, пять слотов
AUX1	Auxilary packet, 1 slot	Вспомогательный пакет, один слот
HV1	High Quality Voice, 1 slot	Голос высокого качества, один слот
HV2	High Quality Voice, 2 slots	Голос высокого качества, два слота
HV3	High Quality Voice, 3 slots	Голос высокого качества, три слота
DV	Data Voice	Данные и голос

зашифрованы. В этом разделе определено несколько схем коррекции ошибок и их применение для различных типов пакетов.
Существует три схемы коррекции ошибок, определенных для беспроводной свя­зи Bluetooth:
•     Прямая коррекция ошибок с коэффициентом 1/3
•     Прямая коррекция ошибок с коэффициентом 2/3
•     Схема автоматического запроса повторной передачи
Назначение FEC в полезной информации — уменьшить количество повторных передач за счет способности восстанавливать данные. В тоже время технические требования указывают, что в ситуации, свободной от ошибок, FEC является лиш­ним, поскольку при этом уменьшается пропускная способность. Заголовок пакета всегда защищен прямой коррекцией ошибок с коэффициентом 1/3, так как он со­держит ценную информацию связи и должен быть способен «выдержать» несколь­ко битовых ошибок.
Логические каналы
Логические каналы являются дополнением физических линий связи. В этом разде­ле определены пять логических каналов Bluetooth.
•     LC канал (Link Control — управление связью)
•     LM канал (Link Manager — администратор связи)
•     UA канал (User Asynchronous data — асинхронные пользовательские данные)
•     Ш канал (User Isochronous data — изохронные пользовательские данные)
•     US канал (User Synchronous data — синхронные пользовательские данные)
В таблице 2.12 дано описание каждого логического канала.

 

Таблица 2.12. Логические каналы
Название	Функция	Расположение	Где встречается
LC	Управление связью	Заголовок	Все пакеты
LM	Управление связью	Полезная информация	SCO или ACL
UA	Асинхронные данные пользователя	Полезная информация	ACLiuhSCO-DV
т	Изохронные данные пользователя	Полезная информация	ACLhotSCO-DV
LJS	Синхронные данные пользователя	Полезная информация	SCO

Обеливание данных
Процедура обеливания данных позволяет изменить распределение информации с целью придания ей свойств белого шума.
Такое преобразование позволяет существенно упростить процесс демодуляции ин­формации, который будет сводиться к обработке сигнала в присутствии белого шума.
Процедуры передачи/приема
В этом разделе описан способ использования пакетов, определенных в разделе Пакеты. Рассмотрены потоки ACL, SCO и комбинированные ACL/SCO. Информация, при­веденная здесь, дает возможность понять идею, представленную в разделе Пакеты.
Синхронизация передачи/приема
Синхронизация важна для устойчивой связи. Этот раздел описывает толерант­ность (допустимые отклонения) синхронизации и синхронизацию мастера с под­чиненным устройством. Представление о синхронизации пикосети при обмене данными иллюстрирует рис. 2.13.

Мастер всегда передает в четных слотах. Подчиненное устройство, к которому только что обратились, должно отвечать в следующем (нечетном) слоте. Подчи­ненные устройства должны всегда «слушать» на четных слотах, потому что они ни­когда не знают, когда к ним могут обратиться.
Управление каналом
В этом разделе рассказывается о процедуре установления канала пикосети. Приве­дено описание работы каналов и процедур добавления и исключения устройств пи­косети. Для поддержания этих функций определено девять режимов работы моду­лей Bluetooth. Кроме того, рассмотрена работа разнесенной сети (scatternet). По­дробно рассмотрено устройство и работа часов Bluetooth, которые играют главную роль в FH-синхронизации.
Канал в пикосети определяется рабочими характеристиками мастера. Адрес мас­тера определяет последовательность перестройки частоты и коды доступа к каналу; системные часы мастера определяют фазу в последовательности перестройки час­тоты и устанавливают синхронизацию. Кроме того, мастер контролирует трафик в канале с помощью схемы опроса.
По определению, мастером является тот модуль Bluetooth, который инициирует соединение.


Термины «мастер» и « подчиненное устройство» имеют отношение только к протоколу: на аппаратном уровне модули Bluetooth считаются функцио­нально идентичными. Любое устройство Bluetooth может стать мастером пикосети; нет «всегда подчиненных» устройств. Кроме того, когда пикосеть уже установлена, роли мастер/подчиненное устройство могут поменяться местами.
Часы Bluetooth
Каждый модуль Bluetooth имеет внутренние системные часы, которые устанав­ливают синхронизацию и скачкообразную перестройку частоты приемопередат­чика. Часы Bluetooth получены из собственного независимого генератора так­товых импульсов, который никогда не корректируется и никогда не выключает­ся. Для синхронизации с другими модулями используются только смещения, добавление которых к собственным часам каждого модуля обеспечивает им временные часы Bluetooth, которые взаимно синхронизируются. Необходимо заметить, что часы Bluetooth не имеют отношения ко времени суток, поэтому, они могут быть выставлены на любое значение. Часы Bluetooth обеспечивают тактовые импульсы приемопередатчику Bluetooth. Их разрешающая способ­ность равна половине длительности Rx или Тх слота, т.е. 312.5 мкеек. Часы имеют цикл около одного дня. Для часов Bluetooth необходим 28-битный счет­чик, который проходит цикл за 228 -1. Схема часов Bluetooth изображена на Рис. 2.14.
Синхронизация и скачкообразная перестройка частоты в канале пикосети опре­деляется Bluetooth-часами мастера. Когда пикосеть установлена, часы мастера свя­заны с подчиненными устройствами. Каждое подчиненное устройство добавляет


смещение к своим собственным часам, чтобы быть синхронизированным к часам мастера. Так как часы автономные, то смещения должны регулярно обновляться (корректироваться).
Рис. 2.14. Схема часов Bluetooth
В зависимости от режима в котором находится модуль Bluetooth, часы могут быть различными:
•     Собственные часы (Native Clock — CLKN)
•     Расчетные часы (Estimated Clock — CLKE)


•     Часы мастера (Master Clock — СLK)
CLKN — это собственные автономные часы, которые являются эталоном для всех остальных видов часов. В режимах высокой активности, собственные часы уп­равляются опорным кварцевым генератором с наихудшей временной нестабильно­стью +20 ррт. В маломощных режимах, таких как Standby, Hold, Park и Sniff (таб­лицы 2.13 и 2.17) собственные часы могут управляться маломощным генератором (Low Power Oscillator — LPO) с нестабильностью ±250 ppm.

Рис. 2.15. Формирование CLKE

Расчетные часы (CLKE) и часы мастера (CLK) получаются от опорных CLKN путем добавления смещения. CLKE — это оценка собственных часов получателя, которую осуществляет вызывающий модуль, т.е. смещения добавляются к CLKN вызываемого модуля для приближенного соответствия CLKN получателя (рис. 2.15). Используя CLKN получателя, вызывающий модуль ускоряет установ­ление соединения.

CLK — это часы мастера пикосети. Они используются для всех процессов син­хронизации и распределения в пикосети. Все устройства Bluetooth используют CLK для распределения передачи и приема. CLK формируется из собственных ча­сов (CLKN) и смещения. Для мастера пикосети смещение равно нулю (рис. 2.16), т к. CLK равен его собственным часам (CLKN). Каждое подчиненное устройство добавляет к своим CLKN смещение, такое чтобы CLK совпадало с CLKN мастера (рис.2.17). Хотя все CLKN устройств Bluetooth идут с одинаковой скоростью, из-за обоюдного дрейфа все же возможно возникновение ошибок. Поэтому смещения в подчиненных устройствах должны регулярно корректироваться таким образом, чтобы CLK совпадало с CLKN мастера.

Рис. 2.16. Формирование CLK мастера

Рис. 2.17. Формирование CLK подчиненного устройства
Обзор состояний
На рис. 2.18 изображена диаграмма состояний, использующихся в контроллере связи Bluetooth. Существует два основных состояния: ожидание (Standby) и со­единение (Connection), а также семь промежуточных состояний: вызов (page), ожидание вызова (page scan), запрос (inquiry), ожидание запроса (inquiry scan), ответ мастера (master response), ответ подчиненного устройства (slave response) и ответ на запрос (inquiry response).


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

 

Таблица 2.13
Режим	Описание
Ожидание (STANDBY)	Модуль Bluetooth находится в режиме малой мощности и не активно связывается (не является частью пикосети). Устройство ожидает сигнал на подключение к пикосети
Соединение (CONNECTION)	После того как соединение установлено, пакеты могут посылаться в обоих направлениях
Вызов (Page)	Используется мастером для активации и соединения с подчиненным устройством, которое периодически «просыпается» в режиме ожидание вызова
Ожидание вызова (Page scan)	Потенциальное подчиненное устройство «слушает» свой код доступа устройства (DAC) в течение установленного отрезка времени. Модуль «слушает» на одной частоте достаточно долго для полного сканирования 16 page-частот
Запрос (Inquiry)	Подобно режиму вызов, этот режим используется мастером для обнаружения набора новых устройств. Мастер не признает сообщения ответ на запрос, но продолжает зондировать на различных каналах и в промежутках ожидать ответные пакеты
Ожидание запроса (Inquiry scan)	Подобен режиму ожидание вызова. Однако, в этом режиме потенциальное подчиненное устройство ожидает свой код доступа запроса (IAC) вместо своего адреса
Ответ мастера (Master response)	Мастер вводит этот режим, когда он получает ответ от подчиненного устройства, после того как оно было вызвано
Ответ подчиненного устройства (Slave response)	Подчиненное устройство вводит этот режим при признании своего кода доступа устройства (DAC)
Ответ на запрос (Inquiry response)	Устройство вводит этот режим при признании своего кода доступа запроса (IAC)

Рис. 2.18. Диаграмма состояний контроллера связи Bluetooth

либо команды администратора связи (LM) Bluetooth, либо внутренние сигналы контроллера связи.
Выбор перестройки частоты
Определено десять типов последовательностей скачкообразной перестройки часто­ты: пять для системы с 79 перестройками (т.е.


каналами) и пять для системы с 23 перестройками (показаны в скобках), соответственно.
•     Последовательность для вызова с 32 (16) уникальными частотами для «про­
буждения», распределенными по полосе 79 (23) МГц, с периодом, равным 32 (16).
•     Последовательность для ответа на вызов охватывает 32 (16) уникальных час­
тот для ответа, которые имеют взаимно-однозначное соответствие с текущей по­
следовательностью для вызова.
•     Последовательность для запроса с 32 (16) уникальными частотами для «про­
буждения», распределенными по полосе 79 (23) МГц, с периодом, равным 32 (56).
•     Последовательность для ответа на запрос охватывает 32 (16) уникальных ча­
стот для ответа, которые имеют взаимно-однозначное соответствие с текущей по­
следовательностью для запроса.

•  Канальная последовательность, которая имеет очень большую длину пер№
да, распределяет частоты одинаково по полосе 79 (23) МГц в течение короткого »
тервала времени.
Общая схема выбора частоты
Схема выбора частоты состоит из двух частей:
•     Выбор последовательности;
•     Установление частот в соответствии с последовательностью.
Общая схема выбора частоты представлена на рис. 2.19. Определенная часто' Устанавливается в соответствие с входными параметрами в блоке выбора частот Входные параметры — это собственные часы и текущий адрес мастера.
В состоянии соединение (Connection) собственные часы (CLKN) корректир ются с помощью смещения для соответствия часам мастера (CLK). Используют! только 27 наиболее значимых бита (Most Significant Bit - MSB) часов. В промеж точных состояниях вызов (Page) и запрос (Inquiry) используются все 28 битов ч с«в. Однако в промежуточном состоянии вызов собственные часы не корректир ются.

Адресный вход состоит из 28 бит, т.е. все поле LAP и 4 наименее значимых бита (Least Significant Bit — LSB) поля UAP (см. раздел Адресация устройств). В со­стоянии соединение используется адрес мастера.


В промежуточном состоянии вы­ зов используется адрес вызываемого модуля. В промежуточном состоянии запрос используется UAP/LAP, соответствующий общему коду доступа запроса (GIAC) Выходным параметром является псевдослучайная последовательность из 79 или 23 перестроек частоты.

Рис. 2.19. Общая схема выбора частоты
В 79-канальной системе схема выбора частоты выбирает сегмент из 32 частот, охватывающий диапазон около 64 МГц (рис. 2.20) и проходит по этим частотам один раз в псевдослучайном порядке. Далее, выбирается другой 32-частотный сег­мент и т.д. В промежуточных состояниях вызов, ожидание вызова или ответ на вы­зов все время используется 32-частотный сегмент (сегмент выбирается с помощью адреса; разные модули будут иметь различные сегменты). В состоянии соединение на выходе составляется псевдослучайная последовательность, которая перемеща­ется по 79 или 23 частотам, в зависимости от системы. Для 23-канальной системы размер сегмента равен 16 (таблица 2.14). Принцип работы схемы выбора частоты изображен на рис. 2.20.
Аудио интерфейс
Обработка аудиоинформации в беспроводной технологии Bluetooth основана на традиционных методах, т.е. информация кодируется на передающей стороне и де­кодируется на приемной.
Аудиоинформация кодируется одним из двух способов: 8-битным логарифми­ческим или линейным кодами (таблица 2.15). Требуемая схема кодирования голо­са выбирается после согласования администраторов связи двух задействованных модулей.


Рис. 2.20. Схема выбора частоты в состоянии соединение (Connection)
Таблица 2.15

Голосовые кодеки
Линейный	CVSD
8-битный логарифмический (рекомендация ITU-T G.711)	А-функция
	ц-функция

Адресация устройств BD ADDR
Каждый приемопередатчик Bluetooth снабжен уникальным 48-битным адресол устройства Bluetooth (Bluetooth Device Address — BD ADDR). Этот адрес назна чается управлением регистрации IEEE (http://standards.ieee.org/regauth/oui/ index.shtml) для производителей и называется организационно уникальным идеи тификатором (Organizationally Unique Identifier — ОШ).


Организационно уникальный идентификатор определен в IEEE Std 802-1990 \ используется для создания 48- битных универсальных MAC адресов локальных се тей. Это позволяет идентифицировать уникальным образом LAN и MAN станции.
Коммуникации Bluetooth используют этот 48-битный адрес для создания своей собственного формата. Идентификатор поделен на три поля следующим образол (рис. 2.21):
•     Поле LAP (Lower Address Part): нижняя адресная часть, состоящая из 24 би
тов;
•     Поле UAP (Upper Address Part): верхняя адресная часть, состоящая их 8 битов;
•     Поле NAP (Non-significant Address Part): незначимая адресная часть, состоя
Щая из 16 битов.
Поля LAP и UAP формируют значимую часть BDADDR. Полный объем адрес; равен 232.


Рис. 2.21. Формат адреса Bluetooth
Коды доступа
Для сигнализации в системе Bluetooth используются 72-битные и 68-битные ко­ды доступа. Определено три различных кода доступа:
•     Код доступа устройства (DAC);
•     Канальный код доступа (САС);
•     Код доступа запроса (I АС).
Также определены адреса для устройств Bluetooth, находящихся в различных состояниях: адрес активного члена (Active Member Address — AM_ADDR), адрес устройства, находящегося в состоянии парковки (Parked Member Address — PMADDR), адрес требования доступа (Access Request Address — ARADDR).
AM ADDR
Каждому активному подчиненному устройству в пикосети назначается 3-х бит­ный адрес активного члена (AMADDR). Адрес AMADDR, состоящий только из нулей, зарезервирован для широковещательных сообщений. Мастер не имеет AM_ADDR.
Адрес AMADDR назначается подчиненному устройству мастером, когда оно активизируется. Это происходит либо во время установления соединения, либо сразу после выхода подчиненного устройства из режима парковки.
РМ ADDR
Подчиненное устройство в режиме парковки может быть идентифицировано своим BDADDR, или выделенным адресом устройства, находящегося в состоя­нии парковки (РМ ADDR).


Это 8-битный адрес, который назначается подчинен­ ному устройству, как только оно вошло в режим парковки. Адрес PM_ADDR дей­ствителен только в период пребывания подчиненного устройства в режиме парков­ки. Когда подчиненное устройство активизируется, вместо РМ ADDR ему назна­чается адрес активного члена (AMADDR).
AR ADDR
Адрес требования доступа (AR_ADDR) используется подчиненным устройст­вом, находящимся в режиме парковки, для определения «окна», в котором можно послать сообщения с требованием доступа.
Адрес AR ADDR назначается подчиненному устройству, когда оно входит в ре­жим парковки и действителен только во время пребывания в этом режиме. Этот адрес необязательно должен быть уникальным; т.е. различные устройства, находя­щиеся в режиме парковки могут иметь одинаковый ARADDR.

Защита информации
Технология Bluetooth обеспечивает беспроводную передачу между равноправны­ми узлами. Для обеспечения защиты и конфиденциальности информации, система обеспечивает меры защиты как на прикладном, так и на канальном уровне. В каж­дом модуле Bluetooth осуществляются процедуры аутентификации и кодирования. Для поддержки защиты информации на канальном уровне используются четыре различных объекта: уникальный общий адрес для каждого пользователя, два сек­ретных ключа и случайное число, которое различно для каждой транзакции. Опи­сание каждого объекта приведено в таблице 2.16.
Таблица 2.16. Объекты, используемые в процедурах аутентификации и кодирования

Объект	Размер
Уникальные адреса устройства Bluetooth (BD ADDR)	48 бит
Личный ключ пользователя, аутентификация	128 бит
Личный ключ пользователя, кодирование	8-128 бит
Случайное число (RAND)	128 бит

Секретные ключи получаются в процессе инициализации и за время существо­вания пикосети никогда не меняются. Ключ кодирования получается из ключа ау­тентификации в процессе аутентификации. Алгоритм аутентификации всегда ис­пользует 128 бит.


Для алгоритма кодирования, размер ключа может колебаться от 8 до 128 бит. Размер ключа кодирования конфигурируем по двум причинам:
1)     Для учета различий в требованиях, наложенных на криптографические алго­
ритмы в различных странах.
2)  Для обеспечения будущего обновления, для исключения неоправданно доро­
гостоящего перепроектирования алгоритмов и аппаратных средств кодирования.
Увеличение размера ключа является самым простым способом борьбы с потенци­
альными подслушивателями.
2.2.3. Протокол управления связью
Протокол управления связью (Link Manager Protocol — LMP) описывает процеду­ры, использующиеся для установления, защиты и управления линией связи между устройствами Bluetooth. Пакеты LMP не содержат данных пользователя. Раздел LMP включает семь подразделов:
1)      Общий обзор
2)  Формат LMP сообщений
3)  Процедуры и протокольные единицы обмена
4)  Установка соединения
5)  Описание PDU
6)  Режимы тестирования
7)  Обработка ошибок

Общий обзор
LMP сообщения используются для установления, защиты и управления линией связи. Они передаются в полезной информации вместо L2CAP и различаются с по­мощью зарезервированного значения в поле L_CH заголовка полезной информа­ции. LMP сообщения отфильтровываются и не распространяются на высшие уров­ни.
LMP сообщения имеют приоритет над данными пользователя. Это значит, что если LM посылает сообщение, Ь2САР-трафик не будет задерживать это сообще­ние, хотя оно может задерживаться многочисленными повторными передачами baseband-пакетов.
LC не отвечает ни за время, необходимое для доставки сообщения на удаленное устройство, ни за задержки между доставкой сообщения на удаленное устройство и получением отправителем соответствующего уведомления.
Основным содержанием этого раздела является описание установления сеанса связи между парой LM, а не непосредственно LM (рис. 2.22).
Физический уровень  i---------


Рис. 2.22. Роль LMP в процессе установки соединения
Формат LMP сообщений
Протокольные единицы обмена (Protocol Data Units — PDU) LM всегда посыла­ются как однослотовые пакеты, а заголовок полезной информации занимает 1 байт. Два наименее значимых бита в заголовке полезной информации определяют логи­ческий канал. Для протокольных единиц обмена LM этим битам присвоено опреде­ленное значение.
Поле Поток в заголовке полезной информации (см. раздел Baseband, Пакеты) всегда состоит из одного бита и игнорируется на принимающей стороне. Каждой

PDU назначен 7-битный код операции, который используется для того, чтобы од­нозначно определить различные типы PDU. Код операции и однобитный иденти­фикатор транзакции расположены в первом байте тела полезной информации (рис. 2.23). Идентификатор транзакции расположен в наименее значимом бите (LSB). Он равен 0, если PDU принадлежит транзакции, инициированной подчи­ненным устройством. Если PDU содержит один или более параметров, они распо­ложены в полезной информации, начиная со второго байта тела полезной инфор­мации. Количество используемых байтов зависит от длины параметров. Если SCO линия связи представлена с использованием пакетов HV1 и длина содержимого менее 9 байт, PDU могут передаваться в пакетах DV. В противном случае должны использоваться пакеты DM1. Все параметры имеют формат с прямым порядком байт, т.е. первым передается наименее значимый байт.
Источник/пункт назначения PDU определены адресом AM_ADDR в заголовке пакета.

Рис. 2.23. Тело полезной нагрузки при передаче LM PDU
Каждая PDU может быть либо обязательной, либо дополнительной. Админист­ратор связи должен распознавать все дополнительные PDU, которые он принима­ет, и если требуется, посылать соответствующий ответ. Если принятая дополни­тельная PDU не требует ответа, ответ не посылается.
Процедуры и протокольные единицы обмена
Этот раздел является ключевым для специалистов, реализующих нижние уровни протокола Bluetooth.


В нем подробно объясняется механизм работы устройства в пикосети. В таблице 2.17 описаны все процедуры.
Таблица 2.17

Процедура	Функция
Общие ответные сообщения	Используются для того, чтобы сообщить инициатору запроса или команды, была ли команда принята — и возможно, выполнена
Аутентификация	Процедура аутентификации, основанная на схеме вызов-ответ, необходима для подтверждения присутствия потенциальных членов пикосети
Сопряжение	Используется, когда два устройства не имеют общего ключа связи или ключа инициализации. Эта процедура создает ключ, основанный на персональном опознавательном номере (Personal Identification Number — PIN) и случайном числе (RAND)
Изменение ключа связи	Если два устройства соединены, и ключ связи получен из комбинации ключей, линия связи может быть изменена в целях повышения ее защищенности

Изменение текущего ключа связи	Текущий ключ связи может быть полупостоянным ключом связи или временным ключом связи. Замена на временный ключ связи необходима, если пикосеть должна поддерживать зашифрованную радиопередачу, которая в этом случае позволила бы иметь общий ключ связи для всех членов пикосети
Кодирование	Начинает процесс кодирования. Кодирование может использоваться, если была выполнена хотя бы одна аутентификация
Запрос смещения часов	Если подчиненное устройство получает FHS пакет, то всегда вычисляется разница между его собственными часами и часами мастера. Этот запрос заставляет подчиненное устройство включить эту разницу в полезную информацию FHS пакета, таким образом, мастер знает на каком частотном канале подчиненное устройство «просыпается» в режиме Ожидание вызова после того, как оно покинуло пикосеть
Информация о смещении слота	Ответ на Запрос смещения часов
Запрос информации 0 точности синхронизации	Возвращенные параметры точности синхронизации — это долговременный дрейф, измеренный в ррш и длительные колебания, измеренные в миллисекундах. Они используются в режимах Пауза (Hold), Внимание (Sniff) и Парковка (Park). Эти параметры фиксированы для определенного устройства и не должны изменяться при очередных запросах
Версия LMP	Запрос версии протокола LMP
Поддерживаемые особенности	В результате этого запроса возвращаются типы пакетов контроллера связи и свойства, поддерживаемые модулем Bluetooth
Переключение роли мастер/ подчиненное устройство	Т.к. вызывающие устройства всегда становятся мастерами пикосети, иногда необходимо переключение ролей мастер/подчиненное устройство
Запрос имени	Запрос удобного для пользователя имени, связанного с устройством Bluetooth. Это имя должно состоять максимум из 248 байт, закодированных в соответствии со стандартом UTF-8
Отсоединение	Обрывает соединение между двумя устройствами Bluetooth. Это может быть сделано в любое время либо мастером, либо подчиненным устройством. Параметр «причина» включается в сообщение для информирования другой стороны о причине прекращения связи
Пауза (Hold)	Линия связи между двумя устройствами Bluetooth может быть помещена в режим Hold на определенное время. В течение этого времени, от мастера не будет передано ни одного ACL пакета
Внимание (Sniff)	Переводит устройство в режим с малым рабочим циклом, т.е. предполагается, что подчиненное устройство не всегда отвечает на запросы. Когда линия связи находится в режиме Sniff, мастер может начать передачу только в определенный слот
Парковка (Park)	Если у подчиненного устройства нет надобности участвовать в пикосети, но оно все еще должно быть FH-синхронизировано, оно может быть переведено в режим Park. В этом режиме устройство «оставляет» свое место в пикосети, но все еще ресинхронизируется на канал, «пробуждаясь» в моменты появления радиомаяка, отделенные специальным интервалом
Регулирование мощности	Если значение уровня мощности принятого сигнала слишком сильно отличается от необходимого для устройства Bluetooth значения, оно может запрашивать увеличение или уменьшение уровня мощности передачи другого устройства. После получения этого сообщения выходная мощность увеличивается или уменьшается

Выбор между пакетами DM и DH в зависимости от качества канала	Устройство конфигурировано для постоянного использования DM пакетов (защищенных FEC с коэффициентом 2/3), постоянного использования DH пакетов (не защищенных), или для автоматической регулировки типа своих пакетов согласно качеству канала. Эта команда устанавливает DH
Качество обслуживания (Quality of Service - QoS)	Этой командой устанавливается интервал опроса, который определен как максимальное время между последующими передачами от мастера к конкретному подчиненному устройству. Опрос с заданным интервалом происходит всегда, кроме тех случаев, когда случаются коллизии при вызове, ожидании вызова, запросе и ожидании запроса
SCO линии связи	Устанавливает SCO линии связи, которые резервируют регулярные временные интервалы для обмена данными между модулями. Отрезок времени между этими интервалами называется SCO интервалом
Контроль многослотовых пакетов	Количество слотов, которые использует подчиненное устройство в своем возвратном пакете, может быть ограничено. В этой процедуре мастер позволяет подчиненному устройству использовать максимальное количество слотов
Схема вызова	Устанавливает одну из опциональных схем вызова, которая будет использована в следующий раз при вызове модуля. Вызываемое устройство может принять или отклонить эту схему
Управление линией связи	Эта процедура используется для установки значения времени ожидания (timeout), которое необходимо для контроля существования линии связи

Установка соединения
Когда вызывающее устройство создает соединение, включая уровни выше LM, оно посылает LM запрос на соединение с хостом. Когда другая сторона принимает это сообщение, хост информируется о входящем соединении. Удаленное устройство может принимать или отклонять запрос на соединение. Если LMP-запрос на со­единение с хостом принят, запускаются LMP-процедуры защиты (сопряжение, ау­тентификация и кодирование). Если устройство не собирается инициировать дру­гие процедуры защиты в процессе соединения, высылается сообщение о том, что установка закончена.


Схема установления соединения представлена на рис. 2.24. После того как устройства обменяются этими сообщениями по логическому кана­лу, отличному от LMP, может быть передан первый пакет.
Описание PDU
В этом разделе технических требований представлена подробная таблица прото­кольных единиц обмена протокола управления связью. Для каждой PDU опреде­лены следующие характеристики:
•     Длина (в байтах)
•     Код операции
•     Тип пакета
•     Возможное направление передачи
•     Содержание
•     Местоположение в полезной информации

 


Рис.2. 24. Схема установления соединения
Режимы тестирования
Протокол LMP имеет несколько протокольных единиц обмена для поддержания различных режимов тестирования Bluetooth, которые используются для сертифи­кации и испытания на соответствие Bluetooth-стандартам Радио и Baseband.
Для активизации режима тестирования (РТ) на тестируемое устройство (Device Under Test — DUT) посылаются РТ-сообщения. Тестируемое устройство всегда является подчиненным. Администратор связи устройства должен быть способен получать эти сообщения в любое время. Если активизация режима тестирования

возможна, DUT возвращает сообщение об этом и вводит режим тестирования (рис. 2.25). Когда DUT-устройство ввело режим тестирования, ему посылается LMP команда для того, чтобы начать тестирование.
Обработка ошибок
Если LM принимает PDU с нераспознаваемым кодом операции, то он отклоняет ее. Нераспознанный код операции отправляется назад в ответной PDU. Если LM принимает PDU с недопустимыми параметрами, оно отклоняет его с кодом причи­ны «недопустимые параметры LMP».
Если превышено максимальное время ожидания или обнаружена потеря связи, то сторона, которая ожидает ответа, заключает, что процедура закончилась неудачно.
Так как LMP PDU не интерпретируются в реальном времени, то в случае, если оба LM приступают к выполнению одной и той же процедуры, могут случаться коллизии, и обе процедуры не будут выполнены.


В такой ситуации мастер откло­ няет процедуру, начатую подчиненным устройством, с кодом причины «Ошибка LMP. Коллизия при передаче». После этого выполняется процедура, начатая мас­тером.
2.2.4. L2CAP
Протокол управления логической связью и адаптацией (Logical Link Control and Adaptation Protocol — L2CAP) отвечает за предоставление услуг SCO- и ACL-пе-редачи данных на протоколы высших уровней. L2CAP имеет возможность мульти­плексирования протоколов наряду с сегментацией и реассемблированием больших пакетов данных пользователя. L2CAP позволяет высокоуровневым протоколам и приложениям передавать и получать пакеты данных длиной до 64 кбайт. L2CAP также поддерживает концепцию групповых абстракций. Раздел L2CAP содержит семь подразделов:
1)      Введение
2)  Общий процесс
3)  Конечный автомат
4)  Машина состояний
5)  Сигнализация
6)  Опции параметров конфигурации
7)  Базовые элементы обслуживания
Введение
Этот подраздел технических требований Bluetooth дает обзор протокола управле­ния логической связью и адаптацией. Протокол L2CAP расположен над Baseband протоколом и находится на уровне передачи данных (рис. 2.26). Функции L2CAP:
•     СО- и CL- услуги передачи данных для протоколов высших уровней
•     Мультиплексирование протоколов

•     Сегментация и реассемблирование
•     Групповая абстракция
L2CAP позволяет высокоуровневым протоколам и приложениям передавать и принимать пакеты данных L2CAP длиной до 64 кбайт.

Рис. 2.26. Уровни связи между устройствами Bluetooth


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

L СНкод          Логический канал           Информация Q0                        Зарезервирован                Зарезервирован для последующего использования 01                        L2CAP                               Продолжение пакета L2CAP Ю                      L2CAP                             Начало пакета L2CAP 11                        LMP                                   Пакет LMP

В разделе Baseband определено два типа линий связи: синхронные с установле­нием соединения и асинхронные без установления соединения. SCO линии связи поддерживают голосовой трафик в реальном времени, используя зарезервирован­ную полосу пропускания. ACL линии связи поддерживают трафик на основе мак­симальных усилий (best effort).
Протокол L2CAP определен только для ACL линий связи и не обеспечивает поддержки SCO линий связи.
Для ACL линий связи не допускается использование пакетов AUX1. Этот тип пакетов не поддерживает проверку целостности данных с помощью циклического избыточного кода. Поскольку L2CAP зависит от проверки целостности на baseband уровне, пакеты AUX1 никогда не используются для транспортировки данных L2CAP.

Рис. 2.27. Структура ACL заголовка полезной информации для однослотовых пакетов

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

В ACL заголовке 1-битное поле Поток управляется контроллером связи и обыч­но его значение равно 1. Его значение равно 0, когда по ACL линии связи больше не будет передаваться L2CAP трафик. Передача пакета L2CAP со значением поля Поток, равным 1, возобновляет поток входящих пакетов L2CAP.
Функциональные требования L2CAP
Функциональные требования L2CAP включают мультиплексирование протоко­лов, сегментацию и реассемблирование (Segmentation and Reassembly - SAR), a также групповое управление. На рис. 2.29 изображено размещение L2CAP в стеке протоколов Bluetooth. L2CAP находится над протоколом Baseband и взаимодейст­вует с другими протоколами, такими как SDP, RFCOMM и TCS.
Реализация L2CAP должна быть приемлемой для устройств с ограниченными вычислительными ресурсами.


Требования к памяти для реализации протокола так­же должны быть сведены к минимуму.
Сложность протокола должна быть приемлема для персональных компьютеров, PDA, цифровых сотовых телефонов, беспроводных гарнитур и других беспровод­ных устройств, поддерживающих Bluetooth. Более того, протокол должен быть раз­работан таким образом, чтобы достигнуть достаточно высокой эффективности ис­пользования полосы частот.
• Мультиплексирование протоколов
L2CAP поддерживает мультиплексирование протоколов, т.к. протокол Baseband не поддерживает поле Тип, распознающее протоколы высших уровней, которые мультиплексируются выше. Baseband мультиплексирует потоки SCO и ACL. Про­токол L2CAP должен мультиплексировать протоколы высших уровней, такие как

протокол обнаружения услуг, RFCOMM и протокол управления телефонией (рис. 2.29). Мультиплексирование протоколов означает направление пакетов дан­ных на соответствующий протокол более высокого уровня.
•  Сегментация и реассемблирование
По сравнению с проводными физическими средами передачи данных, пакеты данных, определенные протоколом Baseband, ограничены'в размере. L2CAP паке­ты большой длины должны быть сегментированы на многочисленные baseband па­кеты меньшей длины до передачи. Подобным образом, принимаемые baseband па­кеты могут быть реассемблированы в один L2CAP пакет после простой проверки целостности. Функциональные возможности сегментации и реассемблирования необходимы для поддержки протоколов, которые используют пакеты, длина кото­рых превышает длину baseband пакетов.
•  Качество услуг
Процесс установления соединения L2CAP позволяет проводить обмен информа­цией относительно качества услуг (QoS), ожидаемого между двумя модулями Bluetooth. Каждая реализация L2CAP должна контролировать ресурсы, используе­мые протоколом.

Рис. 2.29. Схема мультиплексирования протоколов на уровне L2CAP
•  Группы
Многие протоколы используют концепцию группы адресов. Протокол Baseband поддерживает концепцию пикосети, т.е.


группы устройств, синхронно меняющих частоту, используя одни часы. Групповая абстракция L2CAP позволяет проводить эффективное отображение групп протоколов на пикосети.
Следует отметить свойства, которые НЕ поддерживает L2CAP:
•     L2CAP не передает голос, предназначенный для SCO линий связи;
•     L2CAP не выполняет повторные передачи и вычисление контрольной суммы;
•     L2CAP не поддерживает надежного широковещательного канала;
•     L2CAP не поддерживает концепции глобального группового имени.

Обший процесс
Протокол L2CAP базируется на понятии «каналов». Их использование определяет идентификатор канала (Channel IDentifier — CID). Идентификатор канала — это конечная точка канала L2CAP, использующаяся для демультиплексирования вхо­дящего пакета.
Идентификаторы каналов
Идентификаторы от 0x0001 до 0x003F заразервированы для специальных функ­ции. Нулевой идентификатор (0x0000) определен как недопустимый идентифика­тор и никогда не должен использоваться для конечной точки назначения. В табли­це 2.19 приведены другие зарезервированные CID.
Таблица 2.19. Распределения СШ

его	Описание
0x0000	Нулевой идентификатор
0x0001	Канал сигнализации
0x0002	Канал приема без установления соединения
0x0003-0x003F	Зарезервированный
0x0040-0xFFFF	Динамически распределенный

Операции между устройствами
На рис. 2.30 приведен пример использования СШ при связи между соответст­вующими равноправными объектами L2CAP на отдельных устройствах. Ори­ентированные на соединение каналы передачи данных представляют связь между двумя устройствами, где идентификатор канала идентифицирует каж­дую конечную точку канала. Каналы без установления соединения ограничи­вают поток данных до однонаправленного. Эти каналы используются для под­держки «группы» каналов, где СШ на источнике представляет одно или не­сколько удаленных устройств.


Существует также определенное количество CID, зарезервированных для особых целей. Примером зарезервированного ка­нала является канал сигнализации. Этот канал используется для установления каналов передачи данных, ориентированных на соединение, и для определения изменений характеристик этих каналов. Поддержка каналов сигнализации в объектах L2CAP обязательна. Другие СШ зарезервированы для всех входя­щих потоков данных без установления соединения. В примере, приведенном на рис. 2.30, СШ используется для представления группы, состоящей из уст­ройства 3 и устройства 4. Данные, посланные от этого СШ, направляются на Удаленный канал, зарезервированный для потока данных без установления со­единения.
В таблице 2.20 описаны различные каналы и соответствующие идентификаторы источника и пункта назначения.

 

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

Рис. 2.30. Каналы между устройствами
Диаграмма состояний
В этом разделе описана диаграмма состояний протокола L2CAP для канала с уста­новлением соединения. Диаграмма состояний определяет состояния, события, вле­кущие смену состояний, а также действия, которые должны быть выполнены в от­вет на события. Диаграмма состояний не определена для канала сигнализации и для однонаправленного канала.
Формат пакетов данных
Протокол L2CAP основан на пакетах, но следует модели связи, основанной на каналах. Канал представляет собой поток данных между объектами L2CAP на от­даленных устройствах. Каналы могут быть ориентированными на соединение и без установления соединения. Все поля пакета используют прямой порядок байтов.
Канал ориентированный на соединение
Пакеты данных, ориентированные на соединение, используются для поддержки надежного сеанса связи point-to-point.


На рис. 2.31 изображен формат L2CAP па­кета в канале, ориентированном на соединение.

В пакете определены следующие поля:
•     Длина (16 бит) — указывает размер полезной информации в байтах, исключая
длину заголовка L2CAP. Это поле обеспечивает простую проверку целостности ре-
ассемблированного L2CAP пакета на приемной стороне.
•     ID канала (16 бит) — идентифицирует конечную точку канала назначения пакета.
•     Полезная информация (до 65535 байт) — содержит полезную информацию,
полученную от протокола верхнего уровня (исходящий пакет), или переданную на
протокол верхнего уровня (входящий пакет).
Канал без установления соединения
Пакеты данных без установления соединения поддерживают ненадежные груп­повые связи, которые иногда называются «широковещанием» или многоабонент­ской доставкой сообщений (multicast).
На рис. 2.32 изображена структура CL пакета, который используется для переда­чи данных, ориентированных на группы.

Групповые каналы ненадежны. Протокол L2CAP не гарантирует, что данные, пе­редаваемые группе, достигнут каждого члена этой группы.
Данные, ориентированные на группу, передаются всем членам группы без ис­ключения. Локальное устройство не может быть членом группы.
В пакете определены следующие поля:
• Длина (16 бит) — указывает размер полезной информации, плюс PSM поле (в байтах), исключая длину заголовка L2CAP.

 

•     ID канала (16 бит) — указывает групповой пункт назначения пакета.
•     Мультиплексор протоколов/служб (Protocol/Service Multiplexer — PSM)
(минимум 16 бит) — значения PSM имеют два интервала. Значения первого интер­
вала назначены Bluetooth SIG и служат признаком определенного протокола. Зна­
чения второго диапазона динамически распределены и используются вместе с про­
токолом обнаружения услуг.
•     Полезная информация (до 65535 байт) содержит полезную информацию, ко­


торая должна быть распределена всем членам группы.
Интерфейс групповых служб L2CAP обеспечивает механизм для простого уп­равления группами, включая создание группы, добавление новых членов в группу, исключение членов из группы.
Сигнализация
В этом разделе описаны команды сигнализации, которыми обмениваются два объ­екта L2CAP на удаленных устройствах. Все команды сигнализации передаются на CID 0x0001. Реализация L2CAP определяет адрес устройства Bluetooth, которое передает команды. В одном L2CAP пакете может быть передано несколько команд. На рис. 2.33 изображен общий формат всех команд сигнализации.

Рис. 2.33. Общий формат команд сигнализации, передаваемых между объектами L2CAP на удаленных устройствах
Пакет команд сигнализации содержит следующие поля:
•     Код (8 бит) — определяет тип команды. Если принимающая сторона не рас­
познает поля Код, в ответ посылается пакет, отклоняющий всю команду.
•     Идентификатор (8 бит) — используется для согласования запроса с ответом.
Запрашивающее устройство устанавливает значение этого поля, а отвечающее уст­
ройство использует такое же значение в своем ответе. Для каждой команды должен
использоваться отдельный Идентификатор.
•     Длина (16 бит) — указывает только размер поля данных команды сигнализа­
ции (в байтах). Не включает количество байт в полях Код, Идентификатор и
Длина.
•     Данные (0 и более байт) — это поле с переменной длиной обнаруживается с
помощью поля Длина. Формат поля Данные определяет поле Код.

Опции параметров конфигурации
Опции являются механизмами расширения возможностей, необходимых для вы­полнения различных требований подключения. Опции передаются в форме эле­ментов информации, которые включают тип опции, длину опции, и одно или более поле данных опции (рис. 2.34).
Опция содержит следующие поля:
•    Тип (8 бит) — это поле определяет конфигурируемые параметры.
•    Длина (8 бит) — это поле определяет число байт в полезной информации.


Ес­
ли тип опции не имеет полезной информации, то его длина равна нулю.
•     Данные опции (16 бит) — содержимое этого поля зависит от типа опции.
Типы опций:
•     Модуль максимальной передачи
•     Опция времени ожидания сброса
•     Опция качества обслуживания
Базовые элементы обслуживания
Этот раздел представляет абстрактное описание услуг, предлагаемых L2CAP, на ос­нове базовых элементов и параметров обслуживания. Интерфейс обслуживания ну­жен для тестирования. Интерфейс описан независимо от использования какой-либо определенной реализации. Все значения данных используют прямой порядок байтов.
2.2.5. Протокол обнаружения услуг
Протокол обнаружения услуг (Service Discovery Protocol — SDP) является меха­низмом, посредством которого устройства Bluetooth обнаруживают доступные ус­луги, а также характеристики этих услуг.
Термин «услуги» включает в себя широкий спектр приложений или ресурсов. Доступ к ресурсам может включать информационный доступ к услугам или про­вайдерам услуг.
Услуги могут быть обычными:
•     Печать
•     Поисковая связь
•     Факсимильная связь
Возможны также различные виды доступа к информации:
•     Организация телеконференций
•     Сетевые мосты

•     Точки доступа
•     Возможности электронной коммерции (eCommerce)
Кроме того, существуют другие возможности:
•     Получение доступа к услугам
•     Управление доступом к услугам
•     Рекламирование услуг
Частью функции протокола обнаружения услуг является обеспечение средств обнаружения и получения протоколов, методов доступа, «драйверов», и других ко­дов, необходимых для использования услуг. Кроме того, через этот протокол кон­тролируются другие атрибуты, такие как: управление доступом к услугам, рекла­мирование услуг, выбор между конкурирующими услугами, оплата услуг и т.п.


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

Рис. 2.35. SDP-взаимодействие клиента и сервера

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

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


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

 

Порядок передачи байтов
Протокол обнаружения услуг передает многобайтовые поля в обратном порядке байтов, при котором сначала передаются наиболее значимые байты, а потом наиме­нее значимые.
Формат PDU
Каждая протокольная единица обмена протокола SDP состоит из заголовка PDU, за которым следуют специальные параметры PDU. Заголовок состоит из трех полей: PDU ID, ID транзакции и длина параметра (рис. 2.36).
Определения атрибутов услуг
В раздел SDP Ядра технических требований Bluetooth включены только классы услуг, которые непосредственно поддерживают SDP-сервер.


Дополнительные классы услуг определены в разделе Профили. Вероятно, что последующие модер­низации технических требований Bluetooth будут иметь дополнительные классы услуг и модификации уже существующих.
Интерфейсы связи
Чтобы усовершенствовать большое количество современных коммуникацион­ных приложений беспроводная технология Bluetooth должна взаимодействовать с существующими структурами протоколов и приложений.
Технические требования Bluetooth описывают четыре адаптации:
1)RFCOMM
2)  Взаимодействие с IrDA
3)  Управление телефонией
4)  Требования к взаимодействию для использования Bluetooth в качестве WAP
bearer1.
2.2.6. RFCOMM
RFCOMM — это последовательный протокол связи. Создатели приложений часто используют этот протокол при проектировании функции, которая использует по­следовательный кабель связи.
'Bearer — однонаправленный канал передачи данных. Совокупность средств передачи информа­ции и среды распространения, используемых в процессе информационного обмена

Протокол RFCOMM обеспечивает эмуляцию последовательных портов по про­токолу L2CAP. Протокол основан на стандарте ETSI TS 07.10.
RFCOMM эмулирует последовательные порты EIA/TIA-232 (ANSI/TIA/EIA-232-F-1997) со встроенной схемой для безмодемной эмуляции. Эмуляция также включает передачу состояния цепи передачи голосовых сигналов. В большинстве систем RFCOMM будет частью драйвера порта, который включает объект эмуля­ции последовательного порта.
Фактическое управление потоком данных между RFCOMM и нижним уровнем L2CAP зависит от конкретной реализации. RFCOMM имеет виртуальный меха­низм управления потоком данных.
Раздел посвященный протоколу RFCOMM заканчивается описанием того, как он должен использоваться для эмуляции последовательных портов различных уст­ройств.
•     Устройства типа 1 — оконечные точки связи, такие как компьютеры и принте­
ры.
•     Устройства типа 2 — часть сегмента связи; например, модемы.


2.2.7. Взаимодействие с IrDA
Беспроводной технологией Bluetooth был принят протокол инфракрасного объект­ного обмена (Infrared OBject EXchange - IrOBEX, сокращенно ОВЕХ). Bluetooth-реализация OBEX предлагает такие же возможности для приложений, как и в ие­рархии протокола IrDA. Он является протоколом высокого уровня, который рабо­тает с абстракциями данных (т.е. объектами).
Целью авторов этого раздела технических требований Bluetooth было продемон­стрировать, что можно разрабатывать приложения, которые хорошо функциониру­ют как РАДИОЧАСТОТНЫЕ и как ИНФРАКРАСНЫЕ средства передачи дан­ных с малым радиусом действия. Каждая среда имеет свои преимущества и недо­статки, и некоторые приложения могут работать в обеих средах.
Этот раздел определяет «точку пересечения», где могут сходиться беспроводная технология Bluetooth и приложения IrDA. Этой точкой пересечения является про­токол ОВЕХ.
Протокол ОВЕХ может передавать объект, используя операции Put и Get. Один объект может быть передан в одном или нескольких запросах Put или ответах Get. Модель оперирует и информацией об объекте (т.е. типом), и непосредственно са­мим объектом.
Существует два метода реализации протокола ОВЕХ в системе Bluetooth. Про­токол ОВЕХ может быть реализован с использованием возможностей, определен­ных протоколом RFCOMM или TCP/IP.
В устройствах Bluetooth при реализации ОВЕХ с использованием RFCOMM Должны быть выполнены следующие требования:
1) Устройство, поддерживающее ОВЕХ, должно быть способно функциониро­вать как клиент, как сервер, или и то и другое.

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


Этот раздел технических требо­ваний не определяет, как TCP/IP ставится в соответствие беспроводной связи Bluetooth. Устройства Bluetooth, которые поддерживают протокол ОВЕХ по TCP/IP, должны удовлетворять следующим требованиям:
1)      Устройства, поддерживающие ОВЕХ, должны быть способны функциониро­
вать как клиент, как сервер, или и то, и другое.
2)  Для сервера TCP порт с номером 650 назначен агентством по выделению
имен и уникальных параметров протоколов Internet (Internet Assigned Number
Authority — IANA). Если назначенный номер не подходит, номер порта может при­
нимать значение выше 1023. Однако рекомендуется использование номера TCP
порта (650), определенного IANA.
3)  Клиент должен использовать номер порта (на стороне клиента), который на­
ходится вне диапазона 0-1023.
4)  Приложения (служба/сервер), использующие ОВЕХ, должны быть способны
регистрировать надлежащую информацию в базу данных обнаружения услуг.
Технические требования Bluetooth определяют три прикладных профиля, кото­рые используют ОВЕХ (см. Профили):
1)      Профиль синхронизации
2)  Профиль передачи файлов
3)  Профиль помещения объекта в стек
2.2.8. Протокол управления телефонией
Протокол управления телефонией (Telephony Control Specification — TCS), явля­ется бит-ориентированным протоколом. Этот протокол определяет управление сигнализацией вызова для установления сеансов передачи данных и голоса между устройствами Bluetooth. Кроме того, он определяет процедуры управления мо­бильностью при работе с группами TCS-устройств Bluetooth.
Протокол TCS обладает следующими функциональными возможностями:
•     Управление вызовом (Call Control — СС) — сигнализация для установления и
прекращения сеансов передачи голоса и данных между устройствами Bluetooth.
•     Групповое управление (Group Management — GM) — сигнализация для упро­
щения управления группой устройств Bluetooth.


•     TCS без установления соединения (ConnectionLess — CL) — условия для об­
мена сигнальной информацией, не связанной с текущим запросом.
На рис. 2.37 показано положение протокола TCS в стеке протоколов Bluetooth.


Рис. 2.37. Положение протокола TCS в стеке Bluetooth
2.2.9. Требования к взаимодействию для использования Bluetooth в качестве WAP Bearer
Протокол беспроводных .приложений (Wireless Application Protocol — WAP) спро­ектирован для обеспечения доступа в Интернет с устройств, имеющих те или иные ограничения:
•     Полоса рабочих частот канала связи
•     Объем памяти
•     Производительность
•     Возможности отображения
•     Устройства ввода
В этом разделе рассматривается, как беспроводная технология Bluetooth может быть использована как служба Bearer (однонаправленный канал передачи данных), а также определяются SDP записи, позволяющие обнаружение WAP серверов с их оборудованием.
Описываются требования к взаимодействию для использования беспроводной технологии Bluetooth с протоколом point-to-point (PPP) в качестве однонаправ­ленного канала передачи данных для приложений и протоколов WAP.
Среда WAP обычно состоит из трех типов устройств:
1)     WAP клиент
2)  WAP Ргоху/шлюз
3)  WAP сервер
WAP клиент — устройство, которое использует конечный пользователь. Это мо­жет быть портативный компьютер или мобильный телефон. Отличительной осо­бенностью WAP клиента является наличие дисплея и устройства ввода. WAP-кли-ент соединяется с WAP Proxy/шлюзом через беспроводную сеть.
WAP Proxy/шлюз работает как интерфейс между беспроводной сетью и сетью Интернет. Основной функцией модуля доступа (proxy) является обеспечение ус­луг разрешения DNS имен WAP клиенту и преобразование Интернет-протоколов и форматов содержимого в их WAP эквиваленты.

 


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


WAP сервер выполняет функцию, идентичную функции сервера в сети Интер­нет. Зачастую, WAP сервер является HTTP сервером.

2.2.10.Интерфейс хост-контроллера Bluetooth
Интерфейс хост-контроллера (Host Controller Interface — HCI) обеспечивает еди­ный интерфейсный метод доступа к возможностям аппаратного обеспечения 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-кодирование.


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

Рис. 2.41. Аппаратная архитектура Bluetooth

Между HCI драйвером и HCI контроллером находится транспортный уровень. На ноутбуке, например, этим транспортным уровнем может быть PC-карта или уни­версальная последовательная шина.

Транспортный уровень хост-контроллера описан для каждой физической среды в следующих трех разделах технических требований:
•     Транспортный уровень HCI USB;
•     Транспортный уровень HCI RS23;
•     Транспортный уровень HCI UART.
Управление потоком
Управление потоком данных используется в направлении от хоста к хост-контролле­ру. Оно позволяет избежать заполнения буфера данных хост-контроллера ACL-дан­ными, предназначенными для удаленных устройств, которые не отвечают на запросы.
HCI команды
Интерфейс хост-контроллера обеспечивает единый командный метод доступа к возможностям аппаратного обеспечения Bluetooth. Команды связи HCI дают воз­можность хосту контролировать соединения с другими устройствами Bluetooth на канальном уровне.


Эти команды обычно включают LM для обмена LMP-команда-ми с удаленными устройствами Bluetooth.
2.2.11. Транспортный уровень HCI USB

Рис. 2.42. Взаимосвязь между хостом и радио модулем Bluetooth

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


Аппаратное обеспечение USB может быть реализовано двумя путями:
•     Как USB адаптер (рис. 2.43);
•     Интегрировано в материнскую плату ноутбука.

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

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



2.2.14. Тестирование
Режим тестирования поддерживает тестирование передатчика и приемника Bluetooth. Это предназначено главным образом для сертификации и испытания на соответствие стандартам Радио и Baseband.
Режим тестирования спроектирован таким образом, что он не дает доступа к данным пользователя. Это сделано из соображений безопасности, для того чтобы гарантировать, что никто не сможет включить испытательный режим устройства Bluetooth и получить доступ к данным, минуя всю защиту.
Тестированию посвящены три раздела технических требований:
•     Режим тестирования Bluetooth;
•     Требования на соответствие стандартам;
•     Интерфейс управления тестированием.
Режим тестирования Bluetooth
Тестирование протокола используется, для проверки функциональных возможнос­тей на самых нижних уровнях для всех приложений, компонентов и изделий Bluetooth. Это испытание на соответствие нужно для того, чтобы полностью прове­рить функционирование устройства Bluetooth.
Установка для тестирования состоит из тестируемого устройства (DUT) и тесте­ра (при желании, может использоваться дополнительное измерительное оборудо­вание). Тестер и DUT формируют пикосеть, где тестер действует как мастер и име­ет полный контроль над процедурой тестирования. Тестируемое устройство дейст­вует как подчиненное. Контроль производится по воздушному интерфейсу с ис­пользованием команд протокола управления связью. Схема режима тестирования изображена на рис. 2.46.
Режим тестирования — это специальное состояние модели Bluetooth. Из сообра­жений защиты, устройство в режиме тестирования не может поддерживать «нор­мальную работу». В этом состоянии не могут быть отправлены или получены дан­ные пользователя. Это делается для того, чтобы обезопасить, т.е. исключить не­санкционированное вхождение в режим тестирования и получения нежелательно­го доступа к информации.
Когда DUT-устройство выходит из режима тестирования, оно входит в режим ожидания (Standby).


После отключения питания, устройство Bluetooth должно вернуться в режим ожидания.
2.2.15. Требования на соответствие стандартам
Группа Bluetooth SIG имеет подписанное соглашение, по которому на все изделия, Удовлетворяющие техническим требованиям, выдается лицензия.
В этом разделе приведен обзор требований и программа квалификации Bluetooth. Программа квалификации — это процесс проверки изделия на соответ­ствие техническим требованиям Bluetooth.
В программе квалификации задействованы следующие объекты:

 


Рис. 2.46. Алгоритм режима тестирования
•     Аналитический совет программы квалификации Bluetooth (BQRB);
•     Администратор квалификации Bluetooth (BQA);
•     Квалификационное испытательное оборудование Bluetooth (BQTF);
•     Квалификационная группа Bluetooth (BQB).

Рис. 2.47. Схема квалификационного процесса

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

2.2.16. Интерфейс управления тестированием
jCo всем приложениям, компонентам и изделиям Bluetooth применяются аттеста­ционные испытания.
Интерфейс управления тестированием (Test Control Interface — TCI) Bluetooth используется при проверке выполнения протокольных требований Bluetooth для приложений, компонентов или изделий Bluetooth. Таким образом, интерфейс TCI используется для проверки реализованных функциональных возможностей следу­ющих уровней:
•     Baseband;
•     LMP;
•     L2CAP;
•     HCI, если производитель требует поддержки HCI.
2.3.

Содержание раздела

---

---