SPP (Serial Port Profile)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:28, 20 июня 2017.
Профиль последовательного порта (SPP)
BluetoothLogo.svg.png
Type Bluetooth-профиль
Designer Рику Метсла, Олоф Деллиен, Юхан Сренсен
Designed 5 August 2005 года; 14 years ago (2005-08-05)
Manufacturer Nokia, Ericsson
Bitrate до 128 Кбит/с
Max. devices 2
Protocol RFCOMM


SPP (англ. Serial Port Profile – Профиль последовательного порта) - Bluetooth-профиль эмуляции последовательного порта, основанный на спецификации ETSI 07.10 и протоколе RFCOMM.

Профиль последовательного порта позволяет организовать "прозрачный" беспроводной канал между двумя устройствами, которые ранее были связаны проводным последовательным интерфейсом. Встраиваемый Bluetooth-модуль осуществляет преобразование потока данных, поступающих по проводному асинхронному последовательному каналу.[Источник 1]
Этот профиль является основой для DUN, FAX, HSP и AVRCP.
Максимальная полезная нагрузка профиля последовательного порта составляет 128 байт.

Содержание

Структура и зависимости

Профиль последовательного порта включает в себя такие профили, как профиль удаленного доступа, fax-профиль, профиль гарнитуры, профиль доступа к локальной сети и др.
Профиль имеет зависимости от профиля, в котором он содержится - прямо и косвенно; он зависит от другого профиля, если он повторно использует части этого профиля, неявно или явно ссылаясь на него. Структура профиля последовательного порта

Стек протоколов профиля

На рисунке ниже показаны протоколы и сущности, используемые в этом профиле.
Стек протоколов
Baseband, LMP и L2CAP - это Bluetooth-протоколы 1 и 2 уровня модели OSI. RFCOMM - это Bluetooth-адаптация GSM TS 07.10, обеспечивающая протокол передачи для эмуляции последовательного порта. SDP - протокол обнаружения сервиса Bluetooth.
Уровень эмуляции порта, показанный на рисунке, представляет собой объект, имитирующий последовательный порт или предоставляющий API для приложений.

Конфигурации и роли

На рисунке ниже представлена одна из возможных конфигураций устройств профиля последовательного порта. Конфигурация профиля последовательного порта
Для этого профиля определены следующие роли:
Устройство А(DevA) - устройство, которое берет инициативу на создание соединения с другим устройством (DevA называется инициатором).
Устройство В(DevB) - устройство, которое ожидает подключение другого устройства, чтобы взять инициативу на подключение (DevB называется акцептором).
Стоит отметить, что порядок подключения (от DevA к DevB) необязательно должен иметь какое-либо отношение к порядку запуска унаследованных приложений на каждом из устройств.
Для целей сопоставления профиля последовательного порта с традиционной архитектурой последовательного порта как устройство DevA, так и устройство DevB может выступать в качестве DCE, либо DTE. (RFCOMM-протокол не зависит от DTE-DCE или DTE-DTE).

Требования и сценарии использования

Сценарий, охватываемый этим профилем, выглядит следующим образом:
Настраивая виртуальные последовательные порты на двух устройствах и подключая их с помощью Bluetooth, производится эмуляциия последовательного кабеля между двумя устройствами. Любое унаследованное приложение может быть запущено на любом устройстве, используя виртуальный последовательный порт, как если бы существовал реальный последовательный кабель, соединяющий два устройства.
Этот профиль поддерживает только однослотовые пакеты. Это означает, что этот профиль обеспечивает скорость передачи данных до 128 Кбит / с.
В этом профиле поддерживается только одно соединение. Следовательно, рассматриваются только конфигурации типа «точка-точка». Однако это не означает, что возникают какие-то ограничения на согласованность различных подключений: несколько исполнений этого профиля должны иметь возможность запускаться одновременно на одном устройстве.

Процедуры

Процедура Поддержка в DevA Поддержка в DevB
1. Установка соединения и настройка виртуального последовательного соединения Да Нет
2. Согласие на соединение и установку виртуального последовательного соединения Нет Да
3. Регистрация служебной записи для приложения в локальной базе данных SDP Нет Да

Установка соединения и настройка виртуального последовательного соединения

Эта процедура основана на выполнении шагов, необходимых для установления соединения с эмулированным последовательным портом на удаленном устройстве.

  1. Отправка запроса с помощью SDP, чтобы узнать номер канала сервера RFCOMM нужного приложения на удаленном устройстве. Это включает в себя возможность просмотра портов, которая позволяет пользователю производить выбор среди доступных портов (или служб) в одноранговом устройстве. В качестве альтернативы, если точно известно, какая служба должна контактировать, достаточно найти необходимые параметры, используя идентификатор класса обслуживания, связанный с необходимой службой.
  2. Аутентификация удаленного устройства (необязательный шаг).
  3. Запрос на новый канал L2CAP для удаленного RFCOMM.
  4. Инициирование RFCOMM-сессии на канале L2CAP.
  5. Запуск нового соединения передачи данных во время RFCOMM-сессии с использованием вышеупомянутого номера канала сервера.

После выполнения шага 5 виртуальное последовательное соединение готово для связи между приложениями с обеих сторон.

Согласие на соединение и установку виртуального последовательного соединения

Эта процедура состоит из следующих этапов:

  1. По запросу удаленного устройства производится процедура аутентификации и производится запрос на включение шифрования.
  2. Согласие на новые указания создания канала из L2CAP.
  3. Согласие на создание RFCOMM-сессии на этом канале.
  4. Согласие на создание нового соединения для передачи данных во время RFCOMM-сессии.

Регистрация служебной записи для приложения в локальной базе данных SDP

Эта процедура относится к регистрации служебной записи для эмулируемого последовательного порта в базе данных SDP. Это подразумевает наличие базы данных служб и способность отвечать на запросы SDP.
Все сервисы/приложения, доступные через RFCOMM, должны предоставить служебную запись SDP, которая включает в себя параметры, необходимые для обращения к соответствующей службы/приложения. Чтобы поддерживать унаследованные приложения, запущенные на виртуальных последовательных портах, регистрация сервиса должна выполняться с помощью некоторого вспомогательного приложения, которое помогает пользователю в настройке порта.

Режим питания и обратная связь

Несмотря на то, что требования к мощности могут быть совершенно разными для различных устройств, соединенных посредством профиля последовательного порта, нет необходимости использовать какой-либо режим энергосбережения. Однако, по желанию можно создавать запрос на использование режима с малым потреблением мощности.

Если устройство обнаруживает потерю связи, RFCOMM отключается. Перед возобновлением связи, необходимо вновь выполнить процедуру инициализации RFCOMM-сессии.

Требования к совместимости c RFCOMM

Процедура DevA(инициирование) DevB(инициирование) DevA(ответ) DevB(ответ)
1. Инициализация RFCOMM-сессии Да* Нет* Нет* Да*
2. Закрытие RFCOMM-сессии Да Да Да Да
3. Установка DLC Да Нет* Нет* Да
4. Разъединение DLC Да Да Да Да
5. Управляющие сигналы RS232  ?  ? Да Да
6. Передача информации Да Да N/A N/A
7. Тестирующая команда Нет Нет Да Да
8. Общее управление потоком  ?  ? Да Да
9. Индикация состояния удаленной линии ~ ~ Да Да
10. Согласование параметров DLC ~ ~ Да Да
11. Согласование удаленных портов ~ ~ Да Да

Да* - одновременное использование нескольких RFCOMM-сессий необязательно в протоколе RFCOMM. Несмотря на то, что применение параллельности приветствуется там, где она имеет смысл, этот профиль не предусматривает поддержку параллельных сессий RFCOMM в DevA или DevB.
~ - опция выбирается по желанию.
Нет* - при исполнении ролей, определенных в этом профиле, эти способности не используются.
N/A - передача информации не подтверждена в RFCOMM протоколе.
? - какой из механизмов управления потоком будет использоваться, зависит от поставленной задачи. Однако, если реализация не гарантирует, что для получаемой информации всегда найдется буфер, то передача управления потоком DLC или общего управления потоком является обязательной.

Управляющие сигналы RS232

Все устройства должны отправлять информацию обо всех изменениях в управляющих сигналах RS232 с помощью команды Modem Status.
Поскольку RFCOMM может использоваться с адаптацией под любой тип API, необязательно использовать все управляющие сигналы RS232; единственный необходимый сигнал - сигнал управления потоком. Этот сигнал может отображаться в RTS / CTS или XON / XOFF или других механизмах API.

Индикация состояния удаленной линии

Если локальное устройство передает информацию из последовательного порта, где могут возникать ошибки переполнения или фрейм-ошибки, то требуется информировать другое устройство о любых изменениях состояния линии RS232 с помощью команды индикации состояния удаленной линии.

Согласование удаленных портов

DevA может сообщать DevB параметры порта RS232 с помощью команды управления удаленным портами непосредственно перед установкой DLC. DevA может сделать это, если механизм адаптации API под RFCOMM предоставляет эти параметры.
DevB разрешено отправлять команду «Переадресация удаленных портов».

Требования к совместимости c L2CAP

Процедура Поддержка в DevA/DevB
1. Типы каналов
Connection-oriented канал(с организацией соединения) Да
Connectionless канал(без организации соединения) Нет*
2. Оповещения
Установления соединения Да
Настройки Да
Разрыв соединения Да
Отказ на выполнение команды Да
3. Настройка параметров конигурации
Размер максимального передаваемого блока Да
Время очистки буфера Да
Качество сервиса ~
Контроль ретрансляции и потока ~

~ - опция выбирается по желанию.
Нет* - канал без организации соединения не используется при выполнении этого профиля, но возможно параллельное его использование другими профилями/приложениями.

Типы каналов

В этом профиле должны использоваться только каналы с организацией соединения.
Значение RFCOMM определено в документе Bluetooth-стандартов Assigned Numbers[1] в поле PSM раздела Connection Request packet.

Оповещения

Только DevA может отправить запрос на подключение L2CAP в ходе исполнения этого профиля. Помимо этого, профиль последовательного порта не налагает никаких дополнительных ограничений или требований для оповещений.

Настройка конфигурации

В этом разделе описывается использование параметров конфигурации в профиле последовательного порта.

Размер максимального передаваемого блока

Этот профиль не налагает никаких ограничений на размеры передаваемого блока по сравнению с ограничениями, указанными в L2CAP.

Время очистки буфера

Данные переносятся по надежному каналу L2CAP. Если режим усиленной ретрансляции не согласован для канала L2CAP, то значение времени очистки буфера должно быть установлено на значение по умолчанию 0xffff. Если согласован режим усиленной ретрансляции L2CAP, то значение может быть установлено в соответствии с другими профилями, работающими c одним и тем же логическим транспортным протоколом ACL.

Качество сервиса

Согласование качества сервиса выбирается по желанию в данном профиле.

Контроль потока и ошибок

Если устройство, которое будет передавать большие объемы данных, и принимающее устройство будут подвергнуты радиопомехам, которые могут привести к потерям пакетов, то рекомендуется использовать функцию управления ошибками в L2CAP, которая настраивает канал для использования режима усиленной ретрансляции
Данные по последовательному порту переносятся по надежному каналу L2CAP. Надежность этого канала может быть обеспечена использованием бесконечного времени сброса буфера. Однако, если профиль последовательного порта сосуществует одновременно с другими профилями на одной и той же физической линии, тогда эта конфигурация некорректна и может приводить к конфликтам. Поэтому для устройств, у которых профиль последовательного порта сосуществует с другими профилями, должен быть активирован режим усиленной ретрансляции. Таким образом, канал L2CAP позволяет логическому транспортному протоколу ACL иметь конечное время очистки буфера, подходящее для других профилей.

Требования к совместимости c SDP

Для устройства DevA в профиле последовательного порта не предусмотрено служебных записей SDP. Следующая таблица представляет собой описание формата служебных записей в базе данных SDP устройства DevB. В служебную запись разрешено добавлять дополнительные атрибуты. Версии профиля последовательного порта ниже, чем v1.2, не предоставляли атрибута BluetoothProfileDescriptorList. Новые устройства DevA предполагают, что DevB без этого атрибута не поддерживает данный профиль версии 1.2 или выше.

Атрибут Определение Тип/Размер Значение Значение по умолчанию
ServiceClassIDList Замечание 1
ServiceClass #0 UUID SerialPort, Замечания 1 и 3 Текст ячейки
ProtocolDescriptorList
Protocol ID #0 UUID L2CAP, Замечание 1
Protocol ID #1 UUID RFCOMM, Замечание 1
ProtocolSpecificParameter0 Канал сервера Uint8 N = номер канала сервера
BluetoothProfileDescriptorList
Profile ID #0 Поддерживаемые профили UUID Профиль последовательного порта
Parameter #0 Версия профиля Uint16 0x0102
ServiceName Отображаемое текстовое имя String Задается “COM5”, Замечания 2 и 4

Замечания:

  1. Определено в документе Bluetooth-стандартов Assigned Numbers.
  2. Для поддержки определенного языка для всех «отображаемых» атрибутов необходимо добавить соответствующий оффсет к значению LanguageBaseAttributeIDList.
  3. Класс SerialPort - это самый общий тип сервиса, он позволяет добавлять другие, более конкретные классы услуг.
  4. Значение атрибута ServiceName, представленное в таблице, является просто примером.

Процедуры SDP

Чтобы получить служебные записи, клиентский объект SDP в устройстве DevA подключается и взаимодействует с объектом сервера SDP в устройстве DevB через процедуры SDP и L2CAP.

Примечания

Источники

  1. * Технология Bluetooth® // wless.ru: сайт. URL: http://www.wless.ru/technology/?tech=8 (дата обращения 15.05.2017).

Ссылки/Литература

  • Официальный сайт Bluetooth® // bluetooth.org: сайт. URL: https://www.bluetooth.org (дата обращения 15.05.2017).