- •Раздел 1. Введение 6
- •Раздел 2. Технические требования 30
- •Раздел 5. Заключение 184
- •Раздел 1
- •1.7. Видео по Bluetooth
- •1.14. Infrared
- •1.15. Infrared и Bluetooth
- •1.16. Отличия в скорости
- •1.17. Проводная и беспроводная сеть
- •1.20. Сети HomeRf
- •1.22. Внедрение технологии
- •1.23. Проблемы Bluetooth
- •1.24. Программа квалификации Bluetooth
- •1.25. Рынок для Bluetooth
- •Раздел 2
- •2.2. Ядро
- •2.2.1. Радио
- •2.2.2. Baseband
- •2.2.3. Протокол управления связью
- •2.2.4. L2cap
- •2.2.5. Протокол обнаружения услуг
- •2.2.6. Rfcomm
- •2.2.7. Взаимодействие с IrDa
- •2.2.8. Протокол управления телефонией
- •2.2.9. Требования к взаимодействию для использования Bluetooth в качестве wap Bearer
- •2.2.11. Транспортный уровень hci usb
- •2.2.12. Транспортный уровень hci rs232
- •2.2.13. Транспортный уровень hci uart
- •2.2.14. Тестирование
- •2.2.15. Требования на соответствие стандартам
- •2.3.2. Tcp/udp/ip
- •2.3.3. Овех
- •2.3.4. Wap
- •VCalendar
- •2.4. Профили
- •2.4.1. Профиль общего доступа
- •2.4.2. Профиль последовательного порта
- •2.4.3. Профиль приложения обнаружения услуг
- •2.4.5. Профиль внутренней связи
- •2.4.6. Профиль беспроводной телефонии
- •2.4.8. Профиль коммутируемого выхода в сеть
- •2.4.9. Профиль факса
- •2.4.10. Профиль доступа к локальной сети
- •2.4.11- Профиль передачи файлов
- •2.4.12. Профиль помещения объекта в стек
- •2.4.13. Профиль синхронизации
- •Раздел 3
- •3.1. Обзор технологии и архитектуры построения Bluetooth систем
- •3.2. Архитектура аппаратного модуля
- •3.4.1. Модуль Bluetooth rok 101 007
- •3.4.2. Радио модуль рва 313 02
- •Раздел 3
- •3.5. Bluetooth модули компании Mitsumi
- •3.7. Антенны для устройств Bluetooth
- •3.10. Электромагнитная совместимость сетей Bluetooth и других технологий
- •Раздел 4
- •4.1. Мобильный офис
- •4.2. Организация презентаций
- •4.8. Bluetooth в медицине
- •4.9. Bluetooth в доме
- •4.12. Ограничение использования мобильных телефонов
- •4.13. Мобильная электронная коммерция
- •Раздел 5
- •XDsl, isdn точки доступа. Беспроводные модемы. Беспроводная телефония.
- •Inventel
- •Isdn ism
- •Iso itu jtag l2cap
2.2.5. Протокол обнаружения услуг
Протокол обнаружения услуг (Service Discovery Protocol — SDP) является механизмом, посредством которого устройства Bluetooth обнаруживают доступные услуги, а также характеристики этих услуг.
Термин «услуги» включает в себя широкий спектр приложений или ресурсов. Доступ к ресурсам может включать информационный доступ к услугам или провайдерам услуг.
Услуги могут быть обычными:
Печать
Поисковая связь
Факсимильная связь
Возможны также различные виды доступа к информации:
Организация телеконференций
Сетевые мосты
Точки доступа
Возможности электронной коммерции (eCommerce) Кроме того, существуют другие возможности:
Получение доступа к услугам
Управление доступом к услугам
Рекламирование услуг
Частью функции протокола обнаружения услуг является обеспечение средств обнаружения и получения протоколов, методов доступа, «драйверов», и других кодов, необходимых для использования услуг. Кроме того, через этот протокол контролируются другие атрибуты, такие как: управление доступом к услугам, рекламирование услуг, выбор между конкурирующими услугами, оплата услуг и т.п.
В разделе SDP интерес представляют следующие подразделы:
Общий обзор
Представление данных
Описание протокола
Определения атрибутов услуг
Общий обзор
Механизм обнаружения услуг предоставляет приложениям клиента средства для обнаружения услуг, предоставленных приложениями сервера, а также атрибутов этих услуг. Атрибуты услуг включают тип или класс услуги, а также механизм или протокол, необходимый для получения и использования услуги.
Рис. 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
Взаимодействие с IrDA
Управление телефонией
Требования к взаимодействию для использования Bluetooth в качестве WAP bearer1.