Мобильные телекоммуникации

Поле данных пакета 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, получить указатель на соответствующую запись сервиса. Можно провести поиск и по идентификатору класса.

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

Взаимодействующие приборы в 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, остальные являются опционными.

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

В рамках протокола определена структура интерфейса 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 и т.д.).

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

Рис. 8.9. Формат кадров

Предусмотрено три типа кодов доступа: CAC (Channel Access Code — код доступа к каналу), DAC (Device Access Code — код доступа к устройству) и IAC (Inquiry Access Code – код запроса). Код доступа к каналу CAC идентифицирует пикосеть, в то время как DAC используется для запросов соединения и для их откликов (paging). IAC служит для информационных запросов. Поле код синхронизации (64 бита) состоит из 24-битового адреса узла — инициатора соединения (paging).

Алгоритм вычисления адреса узла обеспечивает достаточно большое расстояние Хэмминга между разными синхрокодами, что гарантирует невозможность перепутывания идентификаторов разных устройств даже в случае приема их с ошибками. Поле хвостовик служит для обеспечения балансировки сигнала по постоянному току и синхронизации. 18-битовый заголовок кадра повторяется трижды (18*3=54 бита), он содержит в себе флаги подтверждения и нумерации, а также средства управления потоком. Поле адрес (AM_ADDR — 3 бита — MAC-адрес) определяет один из восьми узлов, которому предназначен кадр. AM_ADDR однозначно определяет один из сетевых клиентов пикосети. Поле тип (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 последнего образует инициализационный ключ.

Для решения проблем беспроводной связи на уровне города разработан стандарт IEEE 802.16.