
- •Раздел 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.4. L2cap
Протокол управления логической связью и адаптацией (Logical Link Control and Adaptation Protocol — L2CAP) отвечает за предоставление услуг SCO- и ACL-пе-редачи данных на протоколы высших уровней. L2CAP имеет возможность мультиплексирования протоколов наряду с сегментацией и реассемблированием больших пакетов данных пользователя. L2CAP позволяет высокоуровневым протоколам и приложениям передавать и получать пакеты данных длиной до 64 кбайт. L2CAP также поддерживает концепцию групповых абстракций. Раздел L2CAP содержит семь подразделов:
Введение
Общий процесс
Конечный автомат
Машина состояний
Сигнализация
Опции параметров конфигурации
Базовые элементы обслуживания
Введение
Этот подраздел технических требований 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 заголовке 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.
Мультиплексор протоколов/служб (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, на основе базовых элементов и параметров обслуживания. Интерфейс обслуживания нужен для тестирования. Интерфейс описан независимо от использования какой-либо определенной реализации. Все значения данных используют прямой порядок байтов.