
Системы радиосвязи и сети телерадиовещания.-2
.pdf
Рис. 8.1.Семейство стандартов IEEE 802 для построения беспроводных сетей
Стандарт IEEE 802.15.1 (Bluetooth) ориентирован на поддержку высокоскоростных мультимедийных приложений. Следствием является и относительно высокая стоимость сетевых устройств. Стандарт IEEE 802.15.3 ориентирован на ещё большую скорость передачи мультимедийных данных в WPAN, а стандарты IEEE 802.15.3a – на значительно большую скорость передачи данных за счёт использования сверхширокополосных сигналов (Ultra Wide Band, UWB). Разрабатываемый стандарт IEEE 802.15.3c является альтернативой стандарту IEEE 802.15. 3а на физическом уровне. Эти стандарты, по сути, призваны воплотить в жизнь беспроводной прототип компьютерной технологии USB. Форум по продвижению стандарта IEEE 802.15.3a имеет название Wireless USB.
Стандарт IEEE 802.15.4 утверждён в 2003 году и ориентирован на организацию WPAN с небольшими скоростями передачи данных (Low Rate WPANs, LR_WPANs) при радиусе действия сетевых устройств от 10 до 75 м. Скорость передачи данных ограничена величиной 250 кбит/с. Низкая скорость передачи данных, однако, при прочих равных условиях требует и низкого энергопотребления сетевых устройств. Это, в свою очередь, позволяет упростить создание таких устройств, работающих с автономным энергопитанием. Поэтому стандарт имеет вполне конкретную рыночную нишу и ориентирован на разработку дешевых сетевых беспроводных устройств, при необходимости работающих от автономного питания. Помимо низкой скорости передачи данных используются и относительно короткие пакеты данных (до 104 байт). Передача коротких пакетов является отличительной чертой систем управления, мониторинга и сбора данных от сенсоров (датчиков).
Bluetooth
Еще недавно проблем с выбором средства соединения различных устройств друг с другом или с компьютером практически не возникало. Кабель (коаксиальный, витая медная пара, многожильный шлейф) представлялся самым оптимальным и практически единственным решением. Однако появившиеся лэптопы и ноутбуки, сотовые телефоны и персональные цифровые помощники, CD- и МР3-плейеры и масса иных мобильных устройств, часто подсоединяемых как друг к другу, так и к стационарным компьютерам, создали проблему. Кабель стал неудобен – подключаться надо часто, размеры самого кабеля с разъемами едва ли не больше собственно подключаемого устройства и т.д. На этом фоне резко возросла актуальность беспроводных локальных технологий, обеспечивающих столь же простое подключение устройства, сколь просто происходит
обращение к диску собственного персонального компьютера. При этом пользователи не привязаны к какому-либо месту.
Bluetooth. Это короткое слово в последнее время всё чаще и чаще мелькает в новостях. Все уже слышали, что это технология беспроводных сетей. Однако подобные технологии существовали и раньше, но ни одна из них не имела и не имеет такой мощной
ивсесторонней поддержки, и ни про одну из них столько не говорилось. Что же такого особенного в Bluetooth?
Само слово Bluetooth можно перевести как "голубой зуб", или "голубая челюсть", что, конечно же, никоим образом не описывает ни сути технологии, ни чего-либо ещё. В далеком 908 году у ютландского короля Горма Старого и его супруги Тиры родился сын – Харальд. Ему была уготована великая судьба. Харальд I Блаатанд (в поздней транскрипции – Bluetooth, Синезубый - прозвище свое он получил из-за потемневшего переднего зуба (есть, правда, и другие версии)), сумев подчинить своей воле разрозненных викингов, объединил Данию с Южной Норвегией и Южной Швецией, создав единое Датское Королевство. Он же способствовал распространению в Скандинавии христианства, что бесспорно послужило единению культур.
Прошло почти 11 веков. В феврале 1998 года компании Ericsson, IBM, Intel, Toshiba
иNokia решили объединить свои усилия для создания технологии беспроводного соединения мобильных устройств, организовав специальную группу SIG (Special Interest Group). И прозвище короля Харальда I – Bluetooth – вновь стало символом объединения. Видимо, свою роль сыграло и то, что основы технологии были еще в 1994 году проработаны шведской компанией Ericsson. Логотип Bluetooth составляют руны, обозначающие инициалы короля.
Изначально группа была открыта для сотрудничества, и сейчас в Bluetooth SIG Promoters, которая занимается разработкой стандарта, входят 3Com, Ericsson, IBM, Intel, Lucent, Microsoft, Motorola, Nokia, и Toshiba. В настоящее время действует версия 1.0 в
спецификации, выпущенная 1 декабря 1999 года. В момент выпуска спецификации было объявлено, что она не является финальной, и финальная спецификация должна выйти ещё через три года. А эти три года должны уйти на "обкатку в боевых условиях". Кроме вышеперечисленных компаний, в группу Bluetooth может абсолютно бесплатно войти любая компания, которая планирует производить или разрабатывать устройства и ПО на основе спецификаций Bluetooth. В настоящее в эту группу уже вошли около 2500 компаний самых различных направлений, так что перспективы у Bluetooth действительно неплохие.
Спецификация Bluetooth описывает пакетный способ передачи информации с временным мультиплексированием. Радиообмен происходит в полосе частот 2400–2483,5 МГц ISM-диапазона. В радиотракте применен метод расширения спектра посредством частотных скачков и двухуровневая частотная модуляция с фильтром Гаусса (binary
Gaussian Frequency Shift Keying).
Метод частотных скачков подразумевает, что вся отведенная для передачи полоса частот подразделяется на определенное количество подканалов шириной 1 МГц каждый. Канал представляет собой псевдослучайную последовательность скачков по 79 или 23 радиочастотным подканалам (табл. 8.1). Каждый канал делится на временные сегменты продолжительностью 625 мкс, причем каждому сегменту соответствует определенный подканал. Передатчик в каждый момент времени использует только один подканал. Эти скачки происходят синхронно в передатчике и приемнике в заранее зафиксированной псевдослучайной последовательности. За секунду может происходить до 1600 частотных скачков. Такой метод обеспечивает конфиденциальность и некоторую помехозащищенность передач. Помехозащищенность обеспечивается тем, что если на каком-либо подканале передаваемый пакет не смог быть принят, то приемник сообщает об этом и передача пакета повторяется на одном из следующих подканалов, уже на другой частоте.

Таблица 8.1. Разделение полосы частот на подканалы в стандарте Bluetooth
Страна |
|
Частота, MГц |
Диапазон, MГц |
Число каналов |
||
Европа* |
и |
2400 |
– |
2483,5 |
f = 2402 + k |
k=0–78 |
США |
|
|
|
|
|
|
Япония |
|
2471 |
– |
2497 |
f = 2473 + k |
k=0–22 |
Испания |
|
2445 |
– |
2475 |
f = 2449 + k |
k=0–22 |
Франция |
|
2446,5 |
– 2483,5 |
f = 2454 + k |
k=0–22 |
Примечание: *Кроме Испании и Франции
Протокол Bluetooth поддерживает как соединения типа точка-точка, так и точкамноготочка. Два или более использующих один и тот же канал устройства образуют пикосеть (piconet). Одно из устройств работает как основное (master), а остальные – как подчиненные (slaves). В одной пикосети может быть до семи активных подчиненных устройств, при этом остальные подчиненные устройства находятся в состоянии "парковки", оставаясь синхронизированными с основным устройством. Взаимодействующие пикосети образуют “распределенную сеть” (scatternet).
Рис. 8.2. Пикосеть с одним подчиненным устройством (а) ,несколькими (б) и распределенная сеть (в)
В каждой пикосети действует только одно основное устройство, однако подчиненные устройства могут входить в различные пикосети. Кроме того, основное устройство одной пикосети может являться подчиненным в другой (рис. 8.2).
Таким образом, в scatternet могут объединяться столько Bluetooth устройств, сколько необходимо, логические связи могут образовываться так, как это требуется, и могут изменяться как угодно, в случае необходимости. Единственное условие, различные piconet входящие в один scatternet должны иметь разные каналы связи, то есть работать на различных частотах и иметь различные hopping channel. Hopping - это регулярная смена частот, определяемая параметрами hopping sequence. Всего спецификация предусматривает 10 вариантов hopping sequence, 5 с циклом в 79 смен и 5 с циклом в 23
смены. С любым hopping sequence частоты сменяются 1600 hops/sec. Используется hopping для того, что бы бороться с затуханием радиосигнала и интерференцией. В одной же пикосети все устройства синхронизированы по времени и частотам. Последовательность скачков является уникальной для каждой пикосети и определяется адресом ее основного устройства. Длина цикла псевдослучайной последовательности – 227 элементов.
Как уже говорилось, автоматическая установка соединения между Bluetooth устройствами, находящимися в пределах досягаемости является одной из важнейших особенностей Blueooth, поэтому первое, с чего начинается работа Bluetooth устройства в незнакомом окружении - это device discovery, или, по-русски, поиск других Bluetooth устройств. Для этого посылается запрос, и ответ на него зависит не только от наличия в радиусе связи активных Bluetooth устройств, но и от режима в котором находятся эти устройства. На этом этапе возможно три основных режима.
Discoverable mode. Находящиеся в этом режиме устройства всегда отвечают на все полученные ими запросы.
Limited discoverable mode. В этом режиме находятся устройства, которые могут отвечать на запросы только ограниченное время, или должны отвечать только при соблюдении определённых условий.
Non-discoverable mode. Находящиеся в этом режиме устройства, как видно из названия режима, не отвечают на новые запросы.
Но это ещё не всё. Даже если удаётся обнаружить устройство, оно может быть в connectable mode или в non-connectable mode. В non-connectable mode устройство не позволяет настроить некоторые важные параметры соединения, и, таким образом, оно хоть и может быть обнаружено, обмениваться данными с ним не удастся. Если устройство находится в connectable mode, то на этом этапе Bluetooth устройства договариваются между собой об используемом диапазоне частот, размере страниц, количестве и порядке hop’ов, и других физических параметрах соединения.
Если процесс обнаружения устройств прошёл нормально, то новое Bluetooth устройство получает набор адресов доступных Bluetooth устройств, и за этим следует device name discovery, когда новое устройство выясняет имена всех доступных Bluetooth устройств из списка. Каждое Bluetooth устройство должно иметь свой глобально уникальный адрес (вроде как MAC-адреса у сетевых плат), но на уровне пользователя обычно используется не этот адрес, а имя устройства, которое может быть любым, и ему не обязательно быть глобально уникальным. Имя Bluetooth устройства может быть длиной до 248 байт, и использовать кодовую страницу в соответствии с Unicode UTF-8 (при использовании UCS-2, имя может быть укорочено до 82 символов). Спецификация предусматривает, что Bluetooth устройства не обязаны принимать больше первых 40 символов имени другого Bluetooth устройства. Если же Bluetooth устройство обладает экраном ограниченного размера, и ограниченной вычислительной мощью, то количество символов, которое оно примет может быть уменьшено до 20.
Ещё одной из важнейших особенностей Bluetooth является автоматическое подключение Bluetooth устройств к службам, предоставляемым другими Bluetooth устройствами. Поэтому, после того как имеется список имён и адресов, выполняется service discovery, поиск доступных услуг, предоставляемых доступными устройствами. Получение или предоставление каких либо услуг - это то, ради чего всё собственно и затевалось, поэтому для поиска возможных услуг используется специальный протокол, называемый, как несложно догадаться, Service Discovery Protocol (SDP), более подробно он будет описан ниже.
В стандарте Bluetooth предусмотрена дуплексная передача на основе разделения времени (time division duplexing). Основное устройство передает пакеты в нечетные временные сегменты, а подчиненное устройство – в четные (рис.8.3). Пакеты в

зависимости от длины могут занимать до пяти временных сегментов. При этом частота канала не меняется до окончания передачи пакета (рис. 8.4).
Протокол Bluetooth может поддерживать асинхронный канал данных, до трех синхронных (с постоянной скоростью) голосовых каналов или канал с одновременной асинхронной передачей данных и синхронной передачей голоса. Скорость каждого голосового канала – 64 Кбит/с в каждом направлении, асинхронного в асимметричном режиме – до 723,2 Кбит/с в прямом и 57,6 кбит/с в обратном направлениях или до 433,9 Кбит/с в каждом направлении в симметричном режиме.
Рис. 8.3. Временные диаграммы работы канала
Рис. 8.4. Передача пакетов различной длины
Синхронное соединение (SCO) возможно только в режиме точка-точка. Такой вид связи применяется для передачи информации, чувствительной к задержкам – например, голоса. Основное устройство поддерживает до трех синхронных соединений, вспомогательное – до трех синхронных соединений с одним основным устройством или до двух – с разными основными устройствами. При синхронном соединении основное устройство резервирует временные сегменты, следующие через так называемые SCOинтервалы. Даже если пакет принят с ошибкой, повторно при синхронном соединении он не передается.
При асинхронной связи (ACL) используются временные сегменты, не зарезервированные для синхронного соединения. Асинхронное соединение возможно между основным и всеми активными подчиненными устройствами в пикосети. Основное и подчиненное устройства могут поддерживать только одно асинхронное соединение. Поскольку в пикосети может быть несколько подчиненных устройств, конкретное подчиненное устройство отправляет пакет основному, только если в предыдущем временном интервале на его адрес пришел пакет от основного устройства. Если в адресном поле ACL-пакета адрес не указан, пакет считается “широковещательным” – его могут читать все устройства. Асинхронное соединение позволяет повторно передавать пакеты, принятые с ошибками.

|
72 |
54 |
0—2745 |
|
бита |
бита |
бит |
|
|
|
|
|
Код |
Заго |
Передав |
|
доступа |
ловок |
аемая |
|
|
|
информация |
|
|
|
|
Рис. 8.5. Структура пакета
Стандартный пакет Bluetooth содержит код доступа длиной 72 бита, 54-битный заголовок и информационное поле длиной не более 2745 бит (рис. 8.5). Однако пакеты могут быть различных типов. Так, пакет может состоять только из кода доступа (в этом случае его длина равна 68 битам) или кода доступа и заголовка.
4 |
64 бита |
4 |
|
бита |
бита |
||
|
|
Преа |
Слово |
Тр |
|
мбула |
синхронизации |
ейлер |
|
|
|
|
Рис. 8.6. Структура кода доступа
Код доступа идентифицирует пакеты, принадлежащие одной пикосети, а также используется для синхронизации и процедуры запросов. Он включает преамбулу (5 бита), слово синхронизации (64 бита) и трейлер – 4 бита контрольной суммы (рис. 8.6).
|
3 бита |
|
4 |
|
1 |
|
|
1 |
|
|
1 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
|
||||||||||||
|
|
бита |
|
бит |
|
бит |
|
|
бит |
|
|
бит |
|
|
|
|
|||||||||||||
|
|
|||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
AM_ |
|
Т |
|
F |
|
|
A |
|
|
S |
|
|
|
|
ADDR |
|
YPE |
|
LOW |
|
RQN |
|
|
EQN |
|
|
ЕС |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Рис.8.7. Структура заголовка
Заголовок содержит информацию для управления связью и состоит из шести полей
(рис. 8.7):
AM_ADDR – 3-битный адрес активного элемента (active member address); TYPE – 4-битный код типа данных;
FLOW – 1 бит управления потоком данных, показывающий готовность устройства к приему;
ARQN – 1 бит подтверждения правильного приема;
SEQN – 1 бит, служащий для определения последовательности пакетов; HEC – 8-битная контрольная сумма.
Информационное поле, в зависимости от типа пакетов, может содержать либо поля голоса, либо поля данных, либо оба типа полей одновременно.
Безопасность
Естественно, Bluetooth не могла обойтись без такой важной вещи, как технология защиты передаваемых данных, встроенной в сам протокол. В зависимости от выполняемых задач, предусмотренно три режима защиты в которых может находится устройство.
Security mode 1 (non secure), устройство не может самостоятельно инициировать защитные процедуры.
Security mode 2 (service level enforced security), устройство не инициирует защитные процедуры пока не установлено и не настроено соединение. После того как соединение установлено, процедуры защиты обязательны, и определяются типом и требованиями используемых служб.
Security mode 3 (link level enforced security), защитные процедуры инициируются в процессе установления и настройки соединения. Если удалённое устройство не может пройти требований защиты, то соединение не устанавливается.
Естественно, что Security mode 3 и 2 могут использоваться вместе, то есть сначала устанавливается защищённое соединение, а потом оно ещё защищается в соответствии с требованиями и возможностями конкретной службы.
Основой системы безопасности Bluetooth, используемой в Security mode 3, является понятие сеансового ключа, или Bond. Сеансовый ключ генерируется в процессе соединения двух устройств, и используется для идентификации и шифрования передаваемых данных. Для генерации ключа могут использоваться самые различные составляющие, от заранее известных обоим устройствам значений, до физических адресов устройств. Комбинируя защиту на уровне соединения с защитой на уровне приложений (где может использоваться абсолютно любая из существующих на сегодня систем защиты данных) можно создавать достаточно надёжно защищённые соединения. Но всё равно, очевидной слабостью Bluetooth соединений с точки зрения построения защищённых соединений остаётся возможность перехвата трафика, причём для этого даже не придётся использовать какое-либо специфическое оборудование. Впрочем, эта проблема не нова, и в настоящее время часто приходится использовать открытые сети, вроде Интернет, где возможен перехват трафика, для передачи закрытых данных.
Протоколы и службы
При работе устройств Bluetooth используются специфические протоколы для Bluetooth и общие, используемые в различных телекоммуникационных системах. Все они образуют стек протоколов.
|
Таблица 8.2. Протокольный стек Bluetooth |
|
|
|
|
Протокольный стек Bluetooth может быть разделен на 4 слоя |
|
|
|
|
|
Протокольный слой |
Протоколы в стеке |
|
|
|
|
Корневые протоколы "Синего |
Baseland, LMP, L2CAP, SDP |
|
Зуба" (Сore protocol) |
|
|
|
|
|
Протокол замены кабеля |
RFCOMM |
|
|
|
|
Протокол управления |
TCS binary, AT-команды |
|
телефонией |
|
|
|
|
|
Воспринятые протоколы |
PPP, UDP/TCP/IP, OBEX, WAP, |
|
(Adopted protocol) |
vCARD, vCAL, IrMC, WAE |
|
|
|
|
Примером вертикального списка протоколов может служить список vCard/vCal > OBEX > RFCOMM > L2CAD > Baseband, который используется в протокольных задачах обмена информацией о деловых карточках. Этот протокольный стек содержит соглашение о внутреннем представлении объектов (vCard) и протокола передачи через эфир (остальная часть стека).
Различные приложения могут использовать различные протокольные стеки. Тем не менее, каждый их этих стеков использует передачу данных (data link) и физический слой, общий для Bluetooth. Смысл каждого из протоколов, специфических для Bluetooth, может быть объяснен отдельно. Все они были разработаны группой специальных интересов Bluetooth SIG. Протоколы RFCOMM и бинарный протокол управления телефонией TCS
BIN также были разработаны этой группой, но они основаны, соответственно, на стандарте ETSI TS 07.10 и на рекомендации Q.931 Международного союза электросвязи.
Помимо этих протокольных слоев спецификация Bluetooth определяет также интерфейс контроллера головной машины (HCI — Host Controller Interface), который дает командный интерфейс к контроллеру базовой полосы (baseband controller), диспетчеру соединений (link manager), и доступ к аппаратным регистрам статуса и управления.
Три слоя — слой замены кабеля, слой контроля телефонии и слой воспринятых протоколов (adapted protocol layer) — совместно определяют совокупность протоколов, ориентированных на приложения, которые позволяют прикладным задачам исполняться над корневыми протоколами Bluetooth.
Спецификация Bluetooth является открытой и дополнительные протоколы (например, HTTP, FTP и т.д.) могут быть подключены поверх специфических транспортных протоколов Bluetooth или поверх протоколов, ориентированных на приложения.
Корневые протоколы Bluetooth требуются для большинства приборов, тогда как остальные протоколы используются только там, где они нужны.
Базовая полоса
Базовая полоса и уровень управления подключениями Link Control Layer обеспечивают физическую радиочастотную связь между устройствами Bluetooth, образующими пикосеть. Поскольку радиочастотная система Bluetooth является системой прыгающей частоты распределенного спектра, внутри которой пакеты передаются в определенные временные интервалы на определенных частотах, этот уровень использует процедуры опроса и пейджинга для синхронизации (согласования) прыгающей частоты передачи и таймеров различных приборов Bluetooth.
Этот уровень предоставляет два различных способа физического подключения с соответствующими пакетами базовой полосы — синхронным, (SCO) и асинхронным
(ACL).
Протоколы могут передаваться в режиме мультиплексирования по одному и тому же радио-звену (RF link). ACL-пакеты используются только для передачи данных, тогда как SCO-пакет может содержать только аудионформацию, или же представлять собой смесь аудио и данных. Для каждого типа данных, включая сообщения об управлении подключениями и контроле, выделяются специальные каналы.
Модель работы с аудио в Bluetooth сравнительно проста и два устройства Bluetooth могут посылать аудио-данные друг другу и получать их, просто открыв аудио-звено (audio link).
Протокол диспетчера подключений
Протокол диспетчера подключений (LMP — Link Manager Protocol) ответственен за установление подключений между устройствами Bluetooth. Сюда же относятся вопросы безопасности, такие как аутентификация и шифрования, связанные генерированием ключей шифрования и подключения, а также с обменом ключами и их проверкой. LMP имеет более высокий приоритет чем остальные протоколы (например, L2CAP), поэтому если канал занят чем-либо другим, то при необходимости передать LMP сообщение он немедленно освобождается.
Кроме того, менеджер подключений контролирует режимы питания и исполнительные циклы приборов Bluetooth, а также состояние подключения того или иного прибора к пикосети.
Протокол управления логическим подключением и адаптацией
Протокол управления логическим подключением и адаптацией (L2CAP — Logical Link Control and Adaptation Protocol) адаптирует протоколы верхнего уровня над базовой полосой.
Logical Link Control and Adaptation Layer Protocol ака L2CAP, является базовым протоколом передачи данных для Bluetooth. Baseband protocol позволяет устанавливать синхронные (Synchronous Connection-Oriented, ака SCO) и асинхронные (Asynchronous Connection-Less, ака ACL) соединения. L2CAP работает только с асинхронными соединениями. Многие протоколы и службы более высокого уровня используют L2CAP как транспортный протокол. В полном соответствии с идеологией Bluetooth L2CAP является простым протоколом, который предъявляет минимум требований к вычислительным мощностям и размеру оперативной памяти устройств, которые его используют. Основные особенности, заложенные в L2CAP таковы:
Protocol Multiplexing. L2CAP является транспортом для многих протоколов и служб, поэтому он обеспечивает возможность разобраться, к какому протоколу или службе относится переданный пакет, что обеспечивает доставку пакета именно тому, кто его ждёт.
Segmentation and Reassembly.Максимальной длиной пакета для L2CAP является 64 килобайта, для baseband protocol это число ещё меньше, всего 341 байт. Однако, иногда требуется передача больших пакетов, поэтому L2CAP обеспечивает разбивку большого пакета на несколько более мелких, и последующую сборку первоначального пакета.
Quality of Service. Благодаря L2CAP Bluetooth устройства могут отслеживать свободные ресурсы соединения и не позволять, чтобы ширина канала или временные задержки для отслеживаемой службы опускались ниже критических значений.
Groups. L2CAP поддерживает адресацию не одному клиенту, а сразу целой группе.
Протокол обнаружения услуг
Одним из важнейших протоколов Bluetooth, который использует L2CAP в качестве транспортного протокола, является Service Discovery Protocol (SDP)
Сейчас никто не сможет представить все возможные способы использования Bluetooth устройств, поэтому при разработке этого протокола пытались учесть как можно больше ситуаций, которые могут возникнуть. Сейчас действует версия 1.0 этого протокола, и основные особенности, которыми он располагает, в настоящее время таковы:
SDP должен позволять поиск служб по специальным атрибутам этих служб. Например, если имеется несколько принтеров, доступных через Bluetooth, то клиент должен иметь возможность найти именно тот принтер, который ему нужен.
SDP должен позволять клиенту искать службы по классу. Если немного переделать предыдущий пример, то если клиенту понадобится принтер, то должна быть возможность найти именно устройство печати, не зная про него ничего другого.
SDP должен позволять просматривать службы без необходимости знать специфические характеристики этих служб. Например, если устройство предоставляющее какую-либо услугу может управляться только специальным программным обеспечением по какому-либо очень редкому или закрытому протоколу, то для SPD это не будет проблемой, всё равно можно будет получить информацию о доступности и названии службы.
SDP должен предоставлять возможности для обнаружения новых служб, которые появились за время работы.
SDP должен предоставлять возможность узнавать, когда служба становится недоступной из за того, что клиент вышел за пределы связи, или по какой-либо другой причине.
SDP позволяет службам, классам служб и атрибутам служб быть однозначно идентифицированными.
SDP должен позволять одному устройству находить любую службу на любом другом устройстве без обращения к третьему устройству.
SDP должен подходить для использования устройствами с ограниченной функциональностью.
SDP должен позволять увеличивать количество доступной информации о службе. Это означает, что если служба требует подробного и объёмного описания своих возможностей, параметров, ограничений и т. п., то вся эта информация не будет вываливаться на всех, кто просто спросит о доступности службы, а будет предоставлена только тем, кто более пристально заинтересуется именно этой службой.
SDP должен поддерживать использование промежуточных кэширующих агентов для ускорения или повышения эффективности процесса поиска новых служб. Этот пункт не противоречит пункту 7, потому что использование третьего устройства возможно, но не обязательно.
SDP должен быть полностью независим от протоколов более высокого уровня, используемых Bluetooth соединением.
SDP должен работать когда в качестве его транспортного протокола используется
L2CAP.
SDP должен позволять находить и использовать службы которые обеспечивают доступ к другим протоколам обнаружения служб. Это позволяет расширять возможности системы, и использовать службы и устройства которые не имеют
Bluetooth интерфейса.
SDP должен поддерживать создание и определение новых служб без необходимости централизовано регистрироваться.
Кроме этого, есть ряд вещей, которые пока что не входят SDP, но очень возможно, что в следующих редакциях спецификации многие из них станут обязательными:
SDP 1.0 не предоставляет механизма доступа к службам, только информацию о службах.
SDP 1.0 не предоставляет возможности оценивать службы. То есть, с его помощью нельзя автоматически выбрать наиболее подходящую службу, если доступно сразу несколько служб, предоставляющих похожий сервис.
SDP 1.0 не позволяет договариваться о параметрах службы.
SDP 1.0 не позволяет узнать о загруженности службы, или устройства предоставляющего службу.
SDP 1.0 не даёт возможности клиенту управлять службой.
SDP 1.0 не позволяет уведомлять о том, что служба или информация о службе становится недоступной.
SDP 1.0 не позволяет уведомлять о том, что атрибуты службы изменились.
В настоящее время спецификация не описывает интерфейса, через который программы должны обращаться к SDP.
SDP 1.0 в настоящее время не обладает развитым механизмом управления списком служб
SDP 1.0 не позволяет накапливать и регистрировать службы.
Используя протокол Service Discovery Protocol, можно запросить информацию о
самом приборе, о его услугах и о характеристиках этих услуг, а после этого может быть установлено соединение между двумя или несколькими приборами Bluetooth.
Протокол, заменяющий кабель
Ещё одним из протоколов, которые используют L2CAP в качестве транспортного является, как видно из приведённой выше схемы, RFCOMM. Этот протокол эмулирует соединение PPP (point-to-point) по серийному порту (RS-232 или EIATIA-232-E, более