2005 г.

Назад: 4.1.8.2 Стандарт широкополосной беспроводной связи IEEE 802.16
Оглавление: Телекоммуникационные технологии
Вперёд: 4.1.9. Сети DQDB (двойная шина с распределенной очередью)

В 1994 году начались работы по изучению возможности использования мобильных, сетевых коммуникаций. Компании IBM, Nokia, Intel и Toshiba создали консорциум для разработки стандарта беспроводной связи между ЭВМ посредством устройств с ограниченным радиусом действия. Проект получил название BlueTooth в честь короля Норвегии и Дании Гарольда Голубой Зуб (Harald Blaatand, 940-981 годы). Проект являлся конкурентом стандарта IEEE 802.11 (оба стандарта используют один и тот же частотный диапазон, одни и те же 79 каналов). Главной его целью являлось удаление любых кабелей из телефонии, а если получится и из локальных сетей. Очевидно, что в нынешнем виде BlueTooth не может вытеснить 802.11 хотя бы из-за ограничений на максимальный размер сети. Но эта технология быстро развивается и трудно предсказать, какое место она займет в самые ближайшие годы. В 1999 году был выдан 1500-страничный документа v1.0. После этого группа стандартизации IEEE взяла этот документ за основу стандарта 802.15 (физический уровень и уровень передачи данных). В 2002 году IEEE утвердил стандарт 802.15.1. Пока стандарт 802.15 и Bluetooth не идентичны, но ожидается их объединение в самом ближайшем будущем. Технология Bluetooth использует нелицензируемый (практически везде кроме России) частотный диапазон 2,4÷2,4835ГГц. При этом используются широкие защитные полосы: нижняя граница частотного диапазона составляет 2ГГц, а верхняя - 3,5ГГц. Точность заданий частоты (положение центра спектра) задается с точностью ± 75 кГц. Дрейф частоты в этот интервал не входит. Кодирование сигнала осуществляется по двухуровневой схеме GFSK (Gaussian Frequency Shift Keying). Логическому 0 и 1 соответствуют две разные частоты. В оговоренной частотной полосе выделяется 79 радиоканалов по 1 МГц каждый. В некоторых странах используется меньшее число каналов (например, во Франции - 23). Каждый из каналов структурируется с помощью выделения временных слотов (доменов) длительностью 625 мкс (разделение по времени). По мощности передатчики делятся на три класса: 100мВт (для связи до 100м; 20дБм); 2 мВт (до 10м; 4дБм) и 1 мВт (~10см; 0дБм). Коэффициент модуляции при этом лежит в диапазоне (0,28-0,35). Чувствительность приемника должна быть не хуже 70дБм. BER (Bit Error Rate) для приемника должна находиться на уровне <0,1%. Желательно, чтобы приемник имел индикатор мощности входного сигнала (требование является опционным). Для первого класса предусмотрено регулирование мощности. Регулировка осуществляется на основе анализа числа ошибок. Протокол использует коммутацию каналов и пакетов. Передача данных выполняется с использованием алгоритма доступа Time-Division Duplex Multiple Access. Каждый пакет передается с использованием иного частотного канала по отношению к предыдущему. Производится 1600 переключений частоты в секунду. Последовательность переключения частот определяется BD_ADDR мастера. Скачкообразное переключение частоты отводит на переходные процессы 250-260 мксек. Длительность тика часов мастера равна 312,5 мксек, что определяет частоту часов - 3,2 кГц. Допускается временная неопределенность при приеме, равная ±20мксек. Смотри также http://www.palowireless.com/infotooth/tutorial/radio.asp.

Структура протоколов Bluetooth не следует моделям OSI, TCP/IP и даже 802 (ведутся работы по адаптации Bluetooth к модели IEEE 802). Физический уровень протокола соответствует базовым принципам моделей OSI и 802. Разработчики потратили много усилий, чтобы сделать протокол как можно дешевле для реализации. В среднем временная привязка мастерных пакетов не должна дрейфовать больше чем на 20 10^-6 относительно идеальной временной привязки слота в 625мксек. Временной разброс при этом не должен превышать 1 мксек. В спецификации определено 5 уровней: физический, базовый (baseband; смотри http://www.palowireless.com/infotooth/tutorial/baseband.asp), управления каналом LMP (Link Management Protocol; смотри http://www.palowireless.com/infotooth/tutorial/lmp.asp) и L2CAP (Logical Link Control and Adaptation Protocol; смотри http://www.palowireless.com/infotooth/tutorial/l2cap.asp), сетевой и уровень приложений.

На уровне baseband протокола определено 13 типов пакетов. Пакеты ID, NULL, POLL, FHS , DM1 ориентированы на каналы SCO и ACL. Пакеты DH1, AUX1, DM3, DH3, DM5 и DH5 предназначены только для каналов ACL. Кодирование данных в пакетах DM1, DM2 и DM3 осуществляется с привлечением битов четности по алгоритму FEC 2/3 (5 бит управления на 10 бит данных). Форматы пакетов HV1, HV2, HV3 и DV определены только для каналов SCO. Максимальный размер поля данных (341 байт) имеют пакеты DH5. Уровень протокола baseband специфицирует пять логических каналов: LC (Control Channel) и LM (Link Manager) используются на канальном уровне, а UA (User Asynchronous), UI (User Isosynchronous) и US (User Synchronous) служат для асинхронной, изосинхронной и синхронной транспортировки пользовательских данных. Контроллер BlueTooth может работать автономно (Standby) или в режиме соединения. Предусмотрено семь субсостояний, которые используются для добавления клиента или подключения к пикосети: page, page scan, inquiry, inquiry scan, master response, slave response и inquiry response.

Состояние Standby по умолчанию является режимом с пониженным энергопотреблением, при этом работает только внутренний задающий генератор. В состоянии соединения главный узел (master) и клиент (slave) могут обмениваться пакетами, используя код доступа к каналу.

В протоколе baseband предусмотрено три типа схем коррекции ошибок: 1/3 FEC, 2/3 FEC и ARQ.

• В 1/3 FEC каждый бит повторяется три раза.
• В 2/3 FEC используется полиномиальный генератор для получения 15-битовых кодов для исходных 10 бит.
• В схеме ARQ пакеты DM, DH и поле данных пакета DV передаются повторно до тех пор, пока не будет получено подтверждение или не произойдет таймаут. При таймауте возможно продолжение со следующего пакета.

Протоколом baseband рекомендуется использование буферов типа FIFO. Если данные не могут быть приняты, контроллер приема (Link Controller) вставляет в заголовок отклика индикатор stop. Когда передачик получает индикатор stop, он блокирует очереди в FIFO. Получатель может возобновить процесс передачи, послав отправителю индикатор go. Взаимодействие протоколов в рамках Bluetooth показано на рис.1

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

Этап 1
	Процедура inquiry позволяет устройству определить, какие приборы доступны, выяснить адреса и осуществить синхронизацию.
	1.1	Посылаются пакеты inquiry и получаются отклики.
	1.2	Будем считать, что блок (адресат), получивший пакет inquiry, находится в состоянии inquiry scan (тогда он способен принимать такие пакеты)
	1.3	Получатель переходит в состояние inquiry response и посылает отправителю пакет-отклик.

После того как процедура inquiry завершена, соединение может быть установлено с помощью процедуры paging.

Этап 2
	Процедура paging реализует соединение. Для осуществления этой процедуры необходим адрес. Устройство, выполняющее процедуру paging, атоматически становится хозяином этого соединения.
	2.1	Посылается пакет paging
	2.2	Адресат получет этот пакет (находится в состоянии page Scan)
	2.3	Получатель посылает отправителю пакет-отклик (находится в состоянии Slave Response)
	2.4	Инициатор посылает адресату пакет FHS (находится в состоянии Master Response)
	2.5	Получатель посылает отправителю второй пакет-отклик (находится в состоянии Slave Response)
	2.6	Получатель и отправитель устанавливают параметры канала заданные инициатором (находятся в состоянии Master Response & Slave Response)

После установления соединения главный узел (master) посылает пакет POLL, чтобы проверить, синхронизовал ли клиент свои часы и настроился ли на коммутацию частот. Клиент при этом может откликнуться любым пакетом.

Устройство Bluetooth при установлении соединения может работать в четырех режимах: Active, Hold, Sniff и Park (активный, удержание, прослушивание и пассивный, соответственно). Смотри табл. 1.

Таблица 1. Режимы работы BlueTooth

Название режима	Описание
Active	В активном режиме устройство Bluetooth участвует в работе канала. Главный узел (master) диспетчеризует обмены на основе запросов трафика, поступающих от участников. Кроме того, этот режим предусматривает регулярные обмены с целью синхронизации клиентов. Активные клиенты прослушивают домены master-to-slave пакетов. Если к активному клиенту нет обращений, он может пребывать в пассивном состоянии (sleep) до очередной передачи со стороны главного узла
Sniff	Устройства синхронизованные в рамках пикосети могут перейти в режим экономного расходования энергии, когда их активность понижается. В режиме SNIFF, устройство-клиент прослушивает пикосеть с пониженной частотой. Этот режим имеет наивысшую скважность рабочего цикла (наименьшая экономия энергии) из 3 экономичных режимов (sniff, hold и park)
Hold	Устройства синхронизованные в рамках пикосети могут перейти в режим экономного расходования энергии, когда их активность понижается. Главный узел пикосети может перевести клиента в режим HOLD, когда работает только внутренний таймер. устройство-клиент может запросить перевода в режим HOLD. Передача данных возобновляется мгновенно, когда устройство выходит из режима HOLD. Клиент имеет промежуточную скважность (промежуточный уровень экономии энергии) из указанных 3 режимов (sniff, hold и park)
Park	В режиме PARK, устройство еще синхронизовано в рамках пикосети, но не принимает участия в обменах. Пассивные устройства отказываются от своих МАС-адресов (AM_ADDR), прослушивают трафик главного модуля с целью ресинхронизации и отслеживают широковещательные сообщения. Данный режим имеет минимально возможную скважность (максимальная экономия энергии) из указанных 3 режимов (sniff, hold и park). Устройства, находящиеся в режиме park, должны посылать пакеты широковещательно, так как лишены собственного активного адреса.

Протокол L2CAP отвечает за формирование пакетов, деление на кадры и сборку пакетов (вспомним, что нижележащий протокол baseband позволяет иметь пакеты не длиннее 341 байта), которые в данном стандарте могут достигать размера 64 кБ. L2CAP производит мультиплексирование и демультиплексирование для отправителей пакетов, кроме того, протокол ответственен за качество обслуживания как при передаче, так и во время ожидания. На фазе установления соединения L2CAP согласует максимальный размер поля данных, так как не все узлы могут работать с 64-килобайтными пакетами. Этот протокол не используется в случае синхронных коммуникаций. В стандарте Bluetooth предусмотрены обмены как с установлением соединения, так и без. Последний режим называется ASL (Asynchronous Connectionless). Трафик ASL доставляется с использованием принципа макимально возможного сервиса. Никаких гарантий при этом не предоставляется. У подчиненного узла может быть только одно ASL-соединение с главным. Обмен с установлением соединения называется SCO (Synchronous Connection Oriented). Этот вид коммуникаций используется, например, при телефонных переговорах. Здесь для каждого из направлений передачи выделяется фиксированный временной интервал. Повторных передач не производится, вместо этого для случая ошибок применяется их коррекция. У подчиненного узла может быть до 3 соединений типа SCO с главным узлом, каждое из которых представляет собой PCM-канал с пропускной способностью 64кбит/c. Протокол должен поддерживать протокольное мультиплексирование, так как уровень basband не имеет поля тип, позволяющего идентифицировать протокол более высокого уровня. Протокол L2CAP присваивает виртуальным каналам (точка-точка) идентификаторы CID (Channel Identifier). Для целей управления трафиком он целиком полагается на уровень LM (Link Manager) протокола baseband.

Основу сети BlueTooth составляют пикосети (piconet), состоящие из одного главного узла и до семи клиентских узлов, размещенных в радиусе 10м (смотри рис. 2). Все узлы такой сети работают на одной частоте и разделяют общий канал. В одной достаточно большой комнате могут располагаться несколько пикосетей. Эти сети могут связываться друг с другом через мосты. Пикосети, объедиененные вместе составляют рассеянную (scatternet) сеть. Поскольку в каждой пикосети имеется свой master, последовательность и фазы переключения их частот не будут совпадать. Если пикосети взаимодействуют друг с другом, это приводит к понижению пропускной способности. Устройство BlueTooth может выступать в качестве клиента в нескольких пикосетях, но главным узлом (master) может быть только в одной пикосети. Кроме 7 активных клиентских узлов главный узел может поддерживать до 255 пассивных (спящих) узлов (переведенных управляющим узлом в режим пониженного энергопотребления).

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

1. Происходит отключение обоих участников процесса от пикосети и осуществляется переключение TDD (Time Division Duplex) трансиверов.
2. Если требуется, узлы старой пикосети образуют новую пикосеть

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

Самым низким уровнем протокола является уровень радиосвязи. На этом уровне данные передаются от главного узла к подчиненному бит за битом. Все узлы пикосети перестраивают частоту одновременно, последовательность частот определяется главным узлом (М на рис. 1). Главный узел (master) является источником синхронизации для всех клиентов пикосети.

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

Одним из активных состояний узла является paging state. В этом состоянии возможно установление или возобновление соединения. Главный узел в этом состоянии непрерывно посылает в эфир короткие ID-пакеты, содержащие только код доступа устройства (device access code). В рамках одного временного домена посылается два пакета на двух разных частотах. Узел-клиент в состоянии paging прослушивает за время 625 мксек две частоты, проверяя наличие своего кода (ID). Для установления соединения посылается запрос. Отправитель запроса не сообщает ничего кроме своего типа. Узел, который хочет, чтобы о его существовании знали окружающие, периодически (раз в 2,56 сек) прослушивает запросы (состояние inquiry state). Когда пассивное устройство обнаружено главным узлом пикосети (откликнулось пакетом FHS, сообщающем о состоянии внутренних часов, об адресе и т.д.), главный узел формирует и посылает пакет POLL, с целью проверки правильности конфигурационных параметров и готовности к приему данных. Клиент может ответить любым пакетом, но если мастер не получил никакого отклика, он переходит в состояние paging или inquiry. Клиент может подключиться и к другой пикосети, для этого в текущей сети он может запросить перехода в режим park или hold. В режиме sniff клиент имеет несколько свободных временных слотов, чтобы участвовать в обменах с соседними сетями. Терминал, находящийся вне зоны связи, должен пребывать в состоянии page mode. Шлюз-сервер должен выделять достаточно ресурсов для запросов page scanning.

Спецификация Bluetooth v1.1 определяет 13 типов поддерживаемых приложений, которые называются профилями, существует также 12 дополнительных профилей. Профили работают на самом верху иерархии слоев протокола (смотри табл. 2). По существу профили являются регламентациями прикладного уровня.

Таблица 2. Основные и дополнительные профили BlueTooth (смотри http://www.palowireless.com/infotooth/tutorial/profiles.asp)

N	Название	Описание
Оcновные профили
1	GAP (Generic Access Profile)	Процедура управления связью
2	SDAP (Service Discovery Application Profile)	Протокол определения предлагаемых сервисов
3	CTP (Cordless Telephony Profile)	Профиль беспроводной телефонии
4	GOEP (Generic Object Exchange Profile)	Протокол операций клиент-сервер при работе с объектами (обмен данными). Клиентская станция инициирует обмен, но она может выполнять и роль сервера.
5	LAP (LAN Access Profile)	Протокол связи мобильной ЭВМ со стационарной LAN
6	DNP (Dial-up Networking Profile)	Протокол связи ЭВМ с сетью посредством мобильного телефона
7	FP (Fax Profile)	Протокол связи мобильного факса с мобильным телефоном
8	SPP (Serial Port Profile)	Профиль для работы с последовательным портом
9	IP (Intercom Profile)	Мобильные телефоны могут работать, как переносные цифровые рации
10	HS (Headset Profile)	Протокол связи устройства hands-free с мобильным телефоном
11	OPP (Object Push Profile)	Протокол пересылки простых объектов
12	FTP (File Transfer Profile)	Протокол пересылки файлов
13	SP (Synchronization Profile)	Протокол синхронизации PDA с другой ЭВМ
Дополнительные профили
1	ESDP (Extended Service Discovery Profile)	Профиль для реализации процедур Plug and Play
2	A2DR (Advanced Audio Distribution Profile)	Продвинутый профиль рассылки аудио данных
3	AVRCD (Audio Video Remote Control Profile)	Аудио-видео профиль удаленного управления
4	BIP (Basic Imaging Profile)	Базовый профиль работы с изображением
5	BPP (Basic Printing Profile)	Базовый профиль для печати
6	CIP (Common ISDN Access Profile)	Общий профиль доступа к ISDN
7	GAVDP (Generic Audio Video Distribution Profile)	Общий профиль рассылки аудио и видео данных
8	HFR (Hands-Free Profile)	Профиль для освобождения рук (hands-free)
9	HCRP (Hardcopy Cable Replacement Profile)	Протокол замены приборного связного кабеля
10	HID (Human Interface Device Profile)	Профиль для реализации интерфейса с человеком
11	PAN (Personal Area Networking)	Протокол формирования персональной сети
12	SAP (SIM Access Profile)	Протокол доступа к SIM

Профили 5-7 конкурируют с протоколом IEEE 802.11. Профиль удаленного доступа служит для подключения ЭВМ к мобильному телефону, снабженному модемом, без использования проводов. Профайл факс позволяет беспроводным факс-устройствам отсылать и получать факсы посредством мобильного телефона. Профили 8-10 имеют отношение к телефонии, в перспективе мобильный телефон и беспроводная трубка домашнего телефона станут взаимозаменяемы. Профиль 10 представляет собой приложение, позволяющее устройствам hands-free держать связь с базой, что удобно, например, при езде в автомобиле. Профили 11-13 служат для пересылки объектов между беспроводными устройствами. Объектами могут быть изображения, информационные файлы и т.д.

Во главе семейства протоколов находится SDP (Service Description Protocol; смотри http://www.palowireless.com/infotooth/tutorial/sdp.asp), предназначенный для определения услуг, оказываемых удаленным устройствам. С помощью команд данного протокола можно считать данные из локальной БД и определить характеристики удаленного устройства и на основе этой информации выяснить параметры оказываемых услуг. SDP использует модель запрос/отклик, где каждая транзакция включает в себя один запрос и один отклик. С помощью посылки одиночного SDP пакета можно осуществлять простое управление информационным потоком. Такой пакет может не сопровождаться откликом.

Поле данных пакета SDP имеет заголовок, содержащий три поля:

• PDU ID - идентификатор типа поля данных (1 байт)
• TransactionID - идентификатор транзакции (2 байта)
• ParameterLength - длина (в байтах) всех параметров в поле данных (2 байта)

Параметры могут содержать атрибут состояния продолжения (continuation state). Некоторые запросы могут потребовать такого большого отклик, который не поместится в одно поле данных. Тогда SDP-сервер генерирует частичный отклик с параметром состояния продолжения. Аналогичный атрибут должен присутствоать в очередном запросе клиента, требующего следующую порцию данных отклика. Такой запрос имеет только два поля InfoLength (1 байт) и Continuation Information (InfoLength байт).

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

• ServiceRecordHandle
• ServiceClassIDList
• ServiceRecordState
• ServiceID
• ProtocolDescriptionList
• BrowseGroupList
• LanguageBaseAttributeIDList
• ServiceInfoTimeToLive
• BluetoothProfileDescriptorList
• DocumentationURL
• ClientExecutableURL
• IconURL
• ServiceName
• ServiceDescription
• ProviderName

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

Атрибут содержит два компонента: идентификатор (ID) и значение атрибута

• ID атрибута представляет собой 16-битовое число без знака, которое должно быть уникальным для данной сервисной записи. Идентификатор определяет и семантику значения атрибута.
• Значение атрибута представляет собой поле переменной длины, чей смысл определяется идентификатором и ассоциированным с ним классом записи услуг

Различные виды сервиса группируются в классы. Все атрибуты, содержащиеся в записи сервиса, относятся к одному классу. Каждому классу присвоен уникальный идентификатор UUID. UUID представляет собой 128-битовый код, но возможны псевдонимы (16- и 32-битовой длины).

Клиент может, зная значение UUID, получить указатель на соответствующую запись сервиса. Можно провести поиск и по идентификатору класса.

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

Type Descriptor	5-битовый код, составлющий старшие разряды информационного элемента заголовка
Size Descriptor	3-битовый код индекса, за которым следует 0, 8, 16 или 32 бита. Индекс содержит младшие 3 бита информационного элемента заголовка

Взаимодействующие приборы в Bluetooth могут выполнять роль локального устройства (LocDev) или удаленного устройства (RemDev). LocDev - прибор, который может инициировать процедуру выявления доступной услуги. Такой прибор должен содержать по крайней мере клиентскую часть архитектуры SDP. RemDev может быть любым прибором, который участвует в процессе выявления доступных услуг, посылая отклик на запрос LocDev. RemDev должен содержать по крайней мере серверную часть архитектуры SDP. RemDev имеет базу данных сервисных записей.

Прежде чем два устройства Bluetooth начнут взаимодействовать, каждый из них должен:

1. Быть включенным и инициализированным. При инициализации может потребоваться PIN для формирования ключа соединения (link key).
2. Должно быть сформированио Bluetooth соединение, которое может потребовать BD_ADDR других устройств.

Выявление услуг (Service Discovery) поддерживает следующие прикладные примитивы для взаимодействия с другими устройствами:

• serviceSearch();
• serviceBrowse();
• enumerateRemDev();
• terminatePrimitive();

Менеджер канала служит для аутентификации, установления и конфигурации соединения, а также шифрования. Данные управления укладываются в однослотовые кадры. Для транспортировки протокольных данных используются пакеты DM1 (в случае SCO - пакеты РМ1). Заголовки этих пакетов содержат всегда 1 байт. Менеджер канала (LM) обнаруживает другие LM и взаимодействует с ними через посредство протокола LMP. Чтобы выполнить роль провайдера LM использует ниже расположенный контроллер канала (LC). LMP-протокол регламентирует структуру управляющих данных (PDU). Приложение должно поддерживать часть типов PDU, остальные являются опционными.

Таблица 2. Обязательные типы PDU протокола LMP

Функция	Тип PDU	Описание
Изменение ключа канала	LMP_comb_key	Ключ канала получается из комбинационных ключей. Содержимое LMP_comb_key защищается с помощью операции XOR с привлечением текущего ключа канала.
Изменение текущего ключа канала	LMP_temp_rand, LMP_temp_key, LMP_use_semi_permanent_key	Текущий ключ канала может быть полупостоянным или временным ключем канала. Ключ может быть изменен временно, но изменение действует только на время сессии. Изменение временного ключа канала нужно, если пикосеть поддерживает шифрованные бродкасты
Запрос сдвига часов	LMP_clkoffset_req, LMP_clkoffset_res	Когда клиент получает FHS-пакет, вычисляется разность между показанием его часов и часов мастера, записанным в поле данных пакета. Мастер может запросить значение сдвига часов в любое время.
Версия LMP	LMP_version_req, LMP_version_res	Уровень LMP поддерживает запросы версии LMP. Запрашиваемое устройство должно прислать отклик с тремя параметрами: VersNr (номер версии протокола), CompId (служит для отслеживания проблем на нижних протокольных уровнях) и Sub-VersNr (рекомендуется, чтобы фирма имела уникальное значение Sub-VersNr для каждого RF/BB/LM).
Поддерживаемые возможности	LMP_feature_req, LMP_feature_res	Контроллер радио и канала может поддерживать только субнабор типов пакетов и возможностей. Устройство может не посылать никаких пакетов кроме ID, FHS, NULL, POLL, ВM1 или DH1, прежде чем озаботится возможностями других устройств. После выполнения запроса возможностей может быть передана область перекрытия возможностей взаимодействующих устройств.
Запрос имени	LMP_name_req, LMP_name_res	LMP поддерживает запрос имени другого устройства. Имя состоит максимум из 248 байтов (UTF-8)
Запрос разрыва	LMP_detach	Соединение может быть разорвано в любое время по запросу мастера или клиента. В сообщение включаются данные, поясняющие причину разрыва.
Качество обслуживания	LMP_quality_of_service, LMP_quality_of_service_req	LM предоставляет возможности качества обслуживания. Интервал, который определяет максимальное время между последовательными передачами между мастером и заданным клиентом, используется для обеспечения определенной полосы пропускания и RTT.
Управление мультислотовыми пакетами	LMP_max_slot, LMP_max_slot_req	Число слотов, используемых устройством может быть ограничено. Устройство позволяет удаленному устройству использовать максимальное число слотов, послав ему значение LMP_max_slot
Управление каналом	LMP_supervision_timeout	Каждый канал имеет таймер, который используется для управления каналом. Этот таймер служит для детектирования потери связи при уходе устройства из зоны досигаемости, отказа источника питания или другой поломки. Процедура определяет значение таймаута
Установление соединения	LMP_host_connection_req, LMP_setup_complete	Если устройство желает установить соединение, включающее уровни выше LM, оно посылает LMP_host_connection_req. Когда партнер получает такое сообщение, он может принять или отвергнуть предлагаемое соединение, послав LMP_accepted или LMP_not_accepted
Режим проверки	LMP_test_activate, LMP_test_control	LMP имеет PDU для поддержки различных методов тестирования, которые используются на уровне radio и baseband
Обработка ошибок	LMP_not_accepted	Если LM получает PDU с нераспознанным кодом, он реагирует посылкой сообщения LMP_not_accepted

В протоколе Bluetooth определены 4 типа адресов: BD_ADDR, AM_ADDR, PM_ADDR и AR_ADDR.

BD_ADDR	Каждому трансиверу Bluetooth присваивается уникальный 48-битовый адрес прибора. Он содержит 24-битовое поле LAP, 16-битовое поле NAP и 8-битовое поле UAP.
AM_ADDR	3-битовый код. Этот адрес будет рабочим, если клиентский узел пикосети является активным. Он иногда называется МАС-адресом модуля Bluetooth.
PM_ADDR	8-битовый код, идентифицирующий пассивный узел пикосети. PM_ADDR является рабочим, пока подчиненный узел пикосети пассивен (parked).
AR_ADDR	Используется пассивным узлом пикосети (parked), чтобы определить полудомен slave-to-master в окне доступа, которое ему предназначено для отправки сообщений запросов доступа. Адрес является рабочим, пока подчиненный узел пассивен и не обязательно является уникальным.

В рамках протокола определена структура интерфейса HCI (Host Controller Interface; смотри http://www.palowireless.com/infotooth/tutorial/hci.asp). Этот интерфейс осуществляет интеграцию низкоуровневых интерфейсов baseband и программного обеспечения клиента. Спецификация поддерживает работу с интерфейсами RS232, UART и USB. HCI предлагает командный метод доступа к аппаратным возможностям Bluetooth. Канальные команды HCI позволяют управлять канальным уровнем соединения с другими устройствами. В перечень входят команды менеджера канала (LM - Link Manager) предназначенные для обмена LMP-командами с удаленными устройствами. Данные для канала LM транспортируются кадрами DM. Команды HCI Policy используются для воздействия на локальный и удаленный LM. Команды Host Controller, Baseband, Informational и Status предоставляют доступ к различным регистрам интерфейса.

Эмуляция последовательных портов (в частности RS-232) посредством L2CAP осуществляется транспортным протоколом RFCOMM (смотри http://www.palowireless.com/infotooth/tutorial/rfcomm.asp). Протокол базируется на стандарте ETSI TS 07.10. RFCOMM поддерживает до 60 одновременных соединений между приборами. Это могут быть модемы, принтеры или ЭВМ.

Транспортный уровень контроллера устройства обеспечивает обмен специфической HCI-информацией. Спецификация HCI определяет формат команд, событий и данных в рамках обмена между устройством и контроллером. Протокол HCI специфицирует 32 различного рода события (Inquiry Complete Event, Page Scan Repetition Mode Change Event и т.д.).

На рис. 3 показан формат заголовка кадра протокола Bluetooth. Структура заголовка регламентируется уровнем baseband.

Предусмотрено три типа кодов доступа: CAC (Channel Access Code - код доступа к каналу), DAC (Device Access Code) и IAC (Inquiry Access Code). Код доступа к каналу CAC идентифицирует пикосеть, в то время как DAC используется для запросов соединения и для их откликов (paging). IAC служит для информационных запросов. Поле код синхронизации (64 бита) состоит из 24-битового адреса узла - инициатора соединения (paging). Алгоритм его вычисления обеспечивает достаточно большое расстояние Хэмминга между разными синхрокодами, что гарантирует невозможность перепутывния идентификаторов разных устройств даже в случае приема их с ошибками. Поле хвостовик служит для обеспечения балансировки сигнала по постоянному току и синхронизации. 8-битовый заголовок кадра повторяется трижды (18*3=54 бита), он содержит в себе флаги подтверждения и нумерации, а также средства управления потоком. Поле адрес (AM_ADDR - 3 бита - MAC-адрес) задает один из восьми узлов, которому предназначен кадр. Поле тип (4 бита) характеризует тип передаваемого кадра (ACL, SCO, опрос или пустой кадр), метод коррекции ошибок и число временных интервалов, из которых состоит кадр. Бит FLOW (поток) устанавливается подчиненным узлом и уведомляет о том, что его буфер заполнен. Бит ACK (подтверждение) указывает на подтверждение, посылаемое вместе с кадром. Если этот бит =1 предыдущий пакет успешно доставлен. Бит SEQN (последовательность) служит для нумерации кадров, что помогает обнаруживать повторные передачи. Для каждого очередного пакета этот бит инвертируется. Данный протокол предполагает ожидание, поэтому одного бита оказывается достаточно. Поле HEC представляет собой 8-битовую контрольную сумму. Принимающая сторона анализирует все три копии заголовка бит за битом. Значение бита определяется мажоритарной схемой (2 или 3 совпадающие бита из трех определяют истинное значение).

В кадрах ACL используются разные форматы данных. Возможны три варианта: 80, 160 и 240 бит, оставшиеся место используется для коррекции ошибок. По этой причине вариант с 80 битами самый надежный. При этом данные повторяются три раза (80*3=240). Фактически применяется тот же прием, что и в случае заголовка. Поле данных кадра SCO всегда имеет 240 бит. Так как подчиненные узлы могут использовать только нечетные временные домены, им достается 800 доменов в секунду, столько же получает и главный узел. При 80 битах данных в кадре подчиненный узел может передать 64 кбит/c. Этого вполне достаточно для для голосового обмена. При самом ненадежном варианте (240 бит данных на кадр) можно иметь три полнодуплексных голосовой связи. Это и ограничивает максимальное число SCO соединений.

Существует 4 категории пакетов Bluetooth. К первой категории относятся пакеты, общие для всех видов соединений (NULL, POLL, FHS, DM1). Три другие описывают пакеты различной длины: ко второй относятся однослотовые кадры, а к четвертой - кадры, занимающие пять временных слотов. Большинство типов пока не определены. ID-кадры имеют длину 64 бита и используются для пейджинга и запросов. NULL-кадры содержат поля лишь кода доступа и заголовка и используются для передачи подтверждений. Кадры POLL похожи на NULL, но требуют от получателя отклика. Пакеты рассматриваются как широковещательные в пикосети, если поле адреса имеет нулевое значение. Прием широковещательных кадров никогда не подтверждается, а для надежности они передаются несколько раз.

Кадры FHS содержат информацию об адресе, классе устройства и о тактовой частоте передатчика. Эти кадры используются при инициализации новой пикосети или при смене схемы переключения несущей частоты. К этой категории следует отнести и кадры DM1, транспортирующие управляющую информацию. Для синхронных соединений определены несколько кадров, различающихся длиной, HV1, HV2 и HV3 с длинами поля данных 10, 20 и 30 байт, соответственно. Тип кадров HV (High quality Voice) предназначен для трансляции голосовых потоков. Тип кадра DV предназначен для передачи как голоса, так и данных. и содержит 80 бит для голоса и 150 бит для данных. Блок данных защищается посредством CRC и в случае ошибки может пересылаться повторно.

Как и для всех радио средств коммуникации для Bluetooth проблема безопасности крайне актуальна. Безопасность протокола обеспечивается с помощью механизма аутентификации и шифрования передаваемых данных. Ключ авторизации имеет 128 бит. Длина ключа шифрования может лежать в пределах 8-128 бит. Кроме того целям безопасности служат ключи соединения (link key), которые могут быть полупостоянными и временными. Первые хранятся в энергонезависимой памяти, вторые - обновляются при каждом соединении. Устройство может генерировать свой ключ (unit key). Возможно формирование совместного ключа (combination key), при его вычислении используются информация от обоих участников будущего обмена. Особое место занимает мастер-ключ (master key), используемый для рассылки данных нескольким узлам одновременно (используется вместо текущего ключа соединения (current link key)). Для выполнения аутентификации устройству нужно получить от партнера случайное число, сформировать на основе него и своего BD_ADDR некоторый код и отослать его партнеру, который проверяет его корректность. Если общий ключ не сгенерирован, формируется инициализационный ключ. Инициатор процедуры посылает партнеру случайное число, которое в сочетании с идентификатором BD_ADDR последнего образует инициализационный ключ.

Литература

1	http://w3.antd.nist.gov/Hsntg/bt/lmp/lmp.html
2	Eugene A. Gryazin, Service Discovery in Bluetooth http://www.cs.hut.fi/Opinnot/Tik-86.174/SD_in_Bluetooth.pdf
3	Сергей Митилино, Беспроводные сети Bluetooth (http://itc.ua/print.phtml?ID=11177)
4	Э. Таненбаум, Компьютерные сети, Питер, 2003, стр. 361-370.
5	http://www.bluetooth.com
6	http://en.wikipedia.org/wiki/Bluetooth
8	http://www.palowireless.com/infotooth/download.asp (достаточно емкое и последовательное, хотя и конспективное изложение)

Назад: 4.1.8.2 Стандарт широкополосной беспроводной связи IEEE 802.16
Оглавление: Телекоммуникационные технологии
Вперёд: 4.1.9. Сети DQDB (двойная шина с распределенной очередью)