spp протокол что это

Spp протокол что это

Протокол типа SPP (полное название на англ. «Sequenced Packet Protocol») предназначен и используется с целью обеспечения надежной и качественной передачи необходимых данных на транспортном уровне между пользователями. Протокол работает в постоянном режиме с установлением соединения. Основные функции протокола – это обеспечение подтверждения переданных данных, передача массивов данных требуемого объема и сохранение порядка их следования. Для более удобного ознакомления с составом блока SPP следует ознакомиться с нижеприведенной таблицей.

Тип данных

Управление потоком данных

Идентификатор канала (отправителя)

Идентификатор канала (получателя)

Счетчик всех переданных пакетов

Буферы для приема (количество)

Необходимые (требуемые) данные

В данной таблице поле с наименованием «Тип данных» отражает непосредственно тип передаваемых данных. Драйвер SPX полностью игнорирует все значения полей в диапазоне от 00 до FD. Данные значения могут произвольно использоваться программой. Значение поля FE идентифицирует посылаемый запрос разъединения, а FF определяет подтверждение образования разъединения.

Поле «Идентификатор канала (отправителя)», так же как и поле «Идентификатор канала (получателя)» определяют канал обмена в драйвере. Этот драйвер может организовывать несколько возможных каналов обмена одновременно по каждому имеющемуся сокету.

Имеющиеся поля счетчиков идентифицируют номера пакетов как подтвержденных, так и переданных. Поле «Буферы для приема (количество)» показывает сколько в данный момент времени пакетов может принять драйвер.

Максимальная длина пакетов SPP не может быть более чем 576 байтов. Во время организации соединения процессы клиента имеют возможность согласовывать использование пакетов различных размеров. Однако при этом SPP не производит определение характера данного согласования.

Источник

BLE взамен RS-232: SPP-профиль на устройствах Bluetooth Low Energy

В классической беспроводной технологии Bluetooth профиль последовательного порта (SPP) обеспечивает возможность замены проводного интерфейса RS-232 беспроводным соединением между двумя устройствами. В устройствах, работающих на новом Bluetooth-стандарте BLE, структура стека для соединения через последовательный порт – иная. Как же организовать на них замену проводного интерфейса беспроводным соединением?

Изначально созданная для высокоскоростной передачи данных в сетях малого радиуса действия беспроводная технология Bluetooth с течением времени развивалась и совершенствовалась. Последнее существенное изменение произошло с появлением версии 4.0, известной также как Bluetooth Low Energy (BLE). Новейшая принятая спецификация имеет версию 4.2. Для BLE используется также и другое название – Bluetooth Smart.

В Bluetooth при создании соединения между двумя устройствами одно из них, инициирующее соединение, выступает в роли ведущего (Master), а другое будет находиться в роли ведомого (Slave). При этом оба устройства могут действовать как индивидуально (топология Point to Point), так и находясь в составе сети со структурой типа «звезда» (топология Star) (рисунок 1). В этом случае один узел функционирует как центральный и действует в роли ведущего, в то время как все остальные узлы функционируют в роли ведомых.

Рис. 1. Две топологии соединений в Bluetooth

В классическом варианте Bluetooth соединение между двумя точками поддерживается, даже если нет подлежащих передаче данных, что приводит к повышенному расходу энергии от автономного источника питания. Лишь при переходе в спящий режим удается несколько сократить потребляемый от батареи ток. В результате на основе классического Bluetooth практически невозможно реализовать компактные устройства длительного пользования с батарейным питанием. Значительно более экономичный в отношении потребляемого тока стандарт Bluetooth Low Energy позволяет создавать конечные устройства с питанием от батареек пуговичного типа, которые способны работать в течение нескольких месяцев и даже лет.

BLE можно рассматривать как расширение базовой технологии Bluetooth Classic, ориентированное в основном на передачу небольших объемов данных, которое оптимально подходит для Интернета вещей. Сравнение основных характеристик BLE и обычного Bluetooth приведено в таблице 1.

Таблица 1. Сравнение Bluetooth с Bluetooth Low Energy

BLE, как и обычный Bluetooth, работает в нелицензируемом частотном диапазоне 2,4 ГГц, используя 40 каналов вместо 79 в классическом варианте и довольствуясь сокращенным по длительности до 3 мс сеансом связи. При этом максимальный размер передаваемого пакета составляет 27 байт.

BLE использует меньше каналов, но с расширенной полосой пропускания. Как показано на рисунке 2, ширина каждого из 40 каналов Bluetooth Smart составляет 2 МГц. Для передачи служебных сигналов (Advertising) выделены три канала, разнесенные в пределах частотного спектра, чтобы минимизировать влияние помех. В течение сеанса связи используется скачкообразный алгоритм выбора частоты канала.

Рис. 2. Частотные каналы Bluetooth Smart (BLE)

Стек ПО Bluetooth Smart (BLE) для последовательного порта

Спецификация Bluetooth определяет структурные элементы, на базе которых разработчик создает совместимые друг с другом устройства. Архитектура программного обеспечения для устройств BLE имеет послойно упорядоченную структуру, обычно называемую стеком. Наборы протоколов и профили позволяют отдельным устройствам соединяться друг с другом и обмениваться данными определенного типа.

В новых версиях Bluetooth, начиная с 4.0, вводятся два типа устройств: однорежимные и двурежимные. Однорежимные устройства работают лишь с поддержкой спецификации BLE, тогда как двурежимные способны также работать и в режиме классического Bluetooth BR/EDR (с базовой/повышенной скоростью).

На рисунке 3 изображены варианты реализации коммуникационного стека Bluetooth. Имеющийся в обычном Bluetooth профиль последовательного порта (SPP) обеспечивает возможность замены проводного интерфейса RS-232 беспроводным соединением между двумя устройствами.

Рис. 3. Структура коммуникационного стека Bluetooth

Профиль SPP включает протоколы RFCOMM, L2CAP, Link Manager и базовый протокол радиосвязи. RFCOMM (Radio Frequency Communications), создает виртуальный последовательный поток данных и эмулирует управляющие сигналы RS-232.

Далее в дело вступает пакетный протокол L2CAP (Logical Link Control and Adaptation Protocol). Он передает пакеты данных между хостом и подсистемой контроллера Bluetooth через интерфейс HCI (Host to Controller Interface) или напрямую в Link Layer, например, как в BlueNRG (рисунок 4).

Рис. 4. Структура стека BlueNRG

В устройствах BLE используется несколько измененная структура стека для соединения через последовательный порт. Вместо SPP имеется профиль атрибутов, а вместо протоколов RFCOMM – протокол атрибутов, оптимизированный для используемых в BLE пакетов данных небольшого размера. Протокол L2CAP остается неизмененным, Link Manager заменен на Link Layer, который определяет для пакетов структуру/каналы, процедуры подключения и отправляемые/получаемые данные.

Последовательный канал связи для устройств BLE

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

В комплекте c оценочными платами производства компании STMicro­electronics имеется пакет ПО для разработки новых устройств, включающий в себя встроенное программное обеспечение, примеры реализации различных сценариев и документацию.

Рассмотрим пример создания канала связи между двумя компьютерами с использованием микросхем BlueNRG-MS или BlueNRG-1, которые являются однорежимными чипами с поддержкой требований BLE из спецификации Bluetooth v4.0. BlueNRG взаимодействуют с микроконтроллером внешнего хоста, используя линии SPI и набор API, состоящий из команд стандартного Application Command Interface (ACI) и определенных производителем команд Host Controller Interface (HCI) (рисунок 4).

Для решения поставленной задачи можно использовать, например, модуль SPBTLE-RF с сетевым процессором BlueNRG-MS (рисунок 5) или другие устройства на основе приемопередатчиков BlueNRG-1. В случае использования BlueNRG-1 расширенные возможности аппаратной платформы позволяют ему в отдельных случаях выполнять также функции приложения и полностью реализовать стек протоколов в одном чипе.

Рис. 5. Модуль ST SPBTLE-RF

Образец программной реализации, которая демонстрирует простое двухполосное соединение между двумя устройствами BlueNRG-MS, доступен в комплекте для разработки ПО (SDK) BlueNRG-MS. Проект называется “BLE Chat”, он размещен в папке “Projects\Projects_STD_Library\BLE_Chat\EWARM_BlueNRG-MS” внутри ПО для оценочного комплекта STEVAL- IDB005V1 или STEVAL-IDB006V1 (рисунок 6).

Рис. 6. Модуль STEVAL-IDB006V1

Те, кто работает с оценочными платами NucleoL152RE и X-NUCLEO-IDB05A1, могут найти этот проект в папке “Projects\Projects_Cube\BLE_Chat\EWARM_BlueNRG-MS”.

Примечание: если работать с BlueNRG-1 в составе оценочной платы STEVAL-IDB007V1, проект можно найти в SDK BlueNRG-1, в папке “\BLE_Examples\BLE_Chat”. Имеется поддержка IAR Embedded Workbench, Keil Microcontroller Development Kit и Atollic TrueSTUDIO.

При работе с этим проектом доступны четыре конфигурации:

В процессе реализации чата BLE выполняются следующие действия:

Сервис Chat содержит две определенные производителем характеристики:

Максимальная длина значения характеристики – 20 байт.

Чтобы установить соединение между двумя устройствами BlueNRG-MS (двумя оценочными платами BlueNRG), необходимо на одном из них реализовать режим «ведущий», а на втором должен быть установлен режим «ведомый». Как только соединение установлено – две точки могут начать передачу данных по каналу связи, используя эти две характеристики.

При использовании оценочных плат участвующие в обмене данные посылаются и принимаются с использованием подключенного к плате через эмулятор терминала на ПК, например, TeraTerm. Каждая оценочная плата будет отображаться на ПК как виртуальный порт COM. Эмулятор терминала конфигурируется следующим образом:

Проектные конфигурации “Client throughput” и “Server throughput” позволяют пользователю тестировать пропускную способность (определенный идентификатор препроцессора “THROUGHPUT_TEST” будет представлен в обеих проектных конфигурациях).

Тест на пропускную способность включает следующие этапы:

Примечание: при работе с BlueNRG-1 в составе оценочной платы STEVAL-IDB007V1 контроллер STM32L1 выполняет роль моста между USB и последовательным портом BlueNRG-1, что позволяет непосредственно проверить пропускную способность от ПК к BlueNRG-1. Прошивка представлена в двоичной форме в SDK BlueNRG-1. Приложение BLE Chat запускается на устройстве BlueNRG-1 и сохраняется во Flash-памяти.

Заключение

Производимые STMicroelectronics приемопередатчики BlueNRG стандарта Bluetooth Low Energy подходят для использования в самом широком спектре устройств персонального назначения, в системах сбора и учета данных, находят широкое применение в промышленной и домашней автоматике.

Встроенное ПО BlueNRG обеспечивает эффективное решение стоящих перед разработчиком задач и не требует от него углубленных познаний в радиочастотной технике и спецификации Bluetooth. Имеющийся в комплекте с SDK набор демонстрационных приложений позволяет использовать некоторые типичные рабочие сценарии BLE.

Постоянно расширяемый набор библиотек ПО, предоставляемые производителем оценочные платы и SDK обеспечивают быстрое начало работ и позволяют в кратчайшие сроки создать законченное устройство с поддержкой Bluetooth Low Energy.

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

SPP (Serial Port Profile)

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

Содержание

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

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

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

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

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

Процедуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы каналов

В этом профиле должны использоваться только каналы с организацией соединения.
Значение 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 или выше.

Процедуры SDP

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

Источник

Архитектуры цифровых сетей

Xerox Network Systems (XNS)

Библиографическая справка

Протоколы Xerox Network Systems ( XNS ) разработаны корпорацией Xerox в конце 1970-начале 1980 гг. Они предназначены для использования в разнообразных средах передачи, процессорах и прикладных задачах офиса. Несколько протоколов XNS похожи на Протокол Internet (IP) и Протокол управления передачей (TCP), разработанных агентством DARPA для Министерства обороны США ( DoD ). Информация по этим и связанным с ними протоколам дается в пункт «Протоколы Internet». Все протоколы XNS соответствуют основным целям проектирования эталонной модели OSI.

Основы технологии

Несмотря на то, что они имеют общие цели проектирования, концепция XNS о иерархии протоколов несколько отличается от той концепции, которую предлагает эталонная модель OSI. На Рис. 4.30 показано приблизительное сравнение XNS и эталонной модели OSI.

Как видно из Рис. 4.30, Xerox обеспечивает 5-уровневую модель передачи пакетов. Уровень 0, который отвечает за доступ к каналу и манипуляцию потока битов, примерно соответствует Уровням 1 и 2 OSI. Уровень 1 примерно соответствует той части Уровня 3 OSI, которая относится к сетевому трафику. Уровень 2 примерно соответствует части Уровня 3, которая связана с маршрутизацией в объединенной сети, и Уровню 4 OSI, который занимается связью внутри отдельных процессов. Уровни 3 и 4 примерно соответствуют двум верхним уровням модели OSI, которые заняты структурированием данных, взаимодействием между отдельными процессами и прикладными задачами. XNS не имеет протокола, соответствующего Уровню 5 OSI ( сеансовый уровень ).

Доступ к среде

Сетевой уровень

Первым полем в пакете IDP является 16- битовое поле контрольной суммы ( checksum ), которое помогает проверить целостность пакета после его прохождения через объединенную сеть.

За полем контрольной суммы следует 16- битовое поле длины ( length ), которое содержит информацию о полной длине (включая контрольную сумму) текущей дейтаграммы.

За полем управления транспортировкой следует 8- битовое поле типа пакета ( packet type ). Это поле определяет формат поля данных.

Каждый из адресов сети источника и назначения имеют три поля: 32- битовый номер сети ( network number ), который уникальным образом обозначает сеть в объединенной сети, 48-битовый номер хоста ( host number ), который является уникальным для всех когда-либо выпущенных хостов, и 16-битовый номер гнезда ( socket number ), который уникальным образом идентифицирует гнездо ( процесс ) в пределах конкретнго хоста. Адреса IEEE 802 эквивалентны номерам хостов, поэтому хосты, подключенные более чем к одной сети IEEE 802, имеют тот же самый адрес в каждом сегменте. Это делает сетевые номера избыточными, но тем не менее полезными для маршрутизации. Некоторые номера гнезд являются хорошо известными (well-known); это означает, что услуга, выполняемая программным обеспечением с использованием этих номеров гнезд, является статически определенной. Все другие номера гнезд допускают многократное использование.

XNS поддерживает пакеты с однопунктовой (из одного пункта в другой пункт), многопунктовой и широковещательной адресацией. Многопунктовые и широковещательные адреса далее делятся на 2 типа: прямые ( directed ) и глобальные ( global ). Прямые многопунктовые адреса доставляют пакеты членам группы многопунктовой адресации данной сети, заданной в адресе сети назначения с многопунктовой адресацией. Прямые широковещательные адреса доставляют пакеты всем членам заданной сети. Глобальные многопунктовые адреса доставляют пакеты всем членам данной группы в пределах всей объединенной сети, в то время как глобальные широковещательные адреса доставляют пакеты во все адреса объединенной сети. Один бит в номере хоста обозначает отдельный адрес в противовес многопунктовому адресу. Все единицы в поле хоста обозначают широковещательный адрес.

Транспортный уровень

Функции транспортного уровня OSI реализуются несколькими протоколами. Каждый из перечисленных ниже протоколов описан в спецификации ХNS как протокол уровня два.

Каждый пакет SPP включает в себя номер последовательности (sequence number), который используется для упорядочивания пакетов и определения тех из них, которые были скопированы или потеряны. Пакеты SPP также содержат два 16-битовых идентификатора соединения ( connection identifier ). Каждый конец соединения определяет один идентификатор соединения. Оба идентификатора соединения вместе уникальным образом идентифицируют логическое соединение между процессами клиента.

Длина пакетов SPP не может быть больше 576 байтов. Процессы клиента могут согласовывать использование различных размеров пакетов во время организации соединения, однако SPP не определяет характер такого согласования.

Протоколы высших уровней

XNS предлагает несколько протоколов высших уровней. Протокол «Печатание» ( Printing ) обеспечивает услуги принтера. Протокол «Ведение картотеки» ( Filing ) обеспечивает услуги доступа к файлам. Протокол «Очистка ( Сlearinghouse ) обеспечивает услуги, связанные с присвоением имени. Каждый из этих протоколов работает в дополнение к протоколу «Курьер» ( Сourier ), который обеспечивает соглашения для структурирования данных и взаимодействия процессов.

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

Источник