Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Архипкин В.Я. Bluetooth. Технические требования. Практическая реализация. Приложения.doc
Скачиваний:
654
Добавлен:
02.05.2014
Размер:
7.92 Mб
Скачать

2.2.4. L2cap

Протокол управления логической связью и адаптацией (Logical Link Control and Adaptation Protocol — L2CAP) отвечает за предоставление услуг SCO- и ACL-пе-редачи данных на протоколы высших уровней. L2CAP имеет возможность мульти­плексирования протоколов наряду с сегментацией и реассемблированием больших пакетов данных пользователя. L2CAP позволяет высокоуровневым протоколам и приложениям передавать и получать пакеты данных длиной до 64 кбайт. L2CAP также поддерживает концепцию групповых абстракций. Раздел L2CAP содержит семь подразделов:

  1. Введение

  2. Общий процесс

  3. Конечный автомат

  4. Машина состояний

  5. Сигнализация

  6. Опции параметров конфигурации

  7. Базовые элементы обслуживания

Введение

Этот подраздел технических требований 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 заголовка полезной информации рассмотрен ниже. На рис. 2.27 изображен заголовок полезной информации, использующийся для однослотовых пакетов, а на рис. 2.28 изображен заголовок, использующийся для многослотовых пакетов. Разница заключается только в длине поля. Тип пакета (в поле baseband-заголовка; см. раздел Baseband, Пакеты) отличает однослотовый пакет от много-слотового.

В 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.

  • ID канала (16 бит) — указывает групповой пункт назначения пакета.

  • Мультиплексор протоколов/служб (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, на ос­нове базовых элементов и параметров обслуживания. Интерфейс обслуживания ну­жен для тестирования. Интерфейс описан независимо от использования какой-либо определенной реализации. Все значения данных используют прямой порядок байтов.