Технология Bluetooth



страница3/6
Дата11.11.2016
Размер3.12 Mb.
Просмотров1665
Скачиваний0
ТипРешение
1   2   3   4   5   6

Модуляция


Для эффективной передачи сигнала (цифрового, аналогового) посредством радио необходимо пройти процедуру модуляции. Позволим себе опустить тонкости различных процессов модуляции сигналов и сконцентрируемся на фактах, которые помогут представить картину спектра в среднестатистическом доме юзера наших дней.

Стандарт 802.11n (а я верю, что у 90% пользователей дома развернут именно он, хотя все нижеизложенное справедливо и для 11g) предусматривает использование OFDM модуляции сигнала с организацией 13 каналов шириной 20 МГц.

https://habrastorage.org/getpro/habr/post_images/ccf/7c3/cd9/ccf7c3cd9495d0cab6e3de46174071fc.png
При этом стандартом 802.11b/g/n предусмотрено использование одного канала на протяжении всего времени работы, если его состояние считается удовлетворительным (читай “нет чередования каналов”).

Bluetooth же использует иной подход: в спектре ISM организуется 79 каналов шириной в 1 МГц, а затем по технологии расширения спектра Frequency-hopping Spread Spectrum (FHSS) радиоприемник и радиопередатчик синхронно меняют частоту несущей по определенному шаблону с частотой 1600 раз в секунду. Сделано это как раз для уменьшения вероятности наложения сигналов в крохотном ISM диапазоне.

https://habrastorage.org/getpro/habr/post_images/d85/9d5/f2c/d859d5f2c04c4254906df2224b7fc850.jpg
Если бы у вас дома был спектральный анализатор, то процесс смены несущей по всему 2.4ГГц диапазону выглядел бы следующим образом:

https://habrastorage.org/getpro/habr/post_images/994/fcf/93e/994fcf93e44efbdd7c653668e2e075cc.png


Случайным образом разбросанные красные точки — это и есть сигнал Bluetooth, постоянно меняющий частоту. Зеленые области — это три активных канала Wi-Fi.

Борьба с интерференцией


Однако техника скоростной смены несущей не избавляет от интерференции, а всего лишь снижает вероятность ее возникновения. Шансы у Bluetooth-сигнала попасть в 20 МГц диапазон канала Wi-Fi по-прежнему ненулевые:

https://habrastorage.org/getpro/habr/post_images/f1b/e76/e9a/f1be76e9a24a70f08a80c68878735103.jpg
Поэтому в арсенале стека Bluetooth есть технология адаптивной смены частоты — Adaptive Frequency Hopping (AFH). Принцип работы AFH состоит в следующем: из 79 доступных 1 МГц каналов исключаются каналы, попадающие в занятый Wi-Fi сигналом диапазон:

https://habrastorage.org/getpro/habr/post_images/3e3/0e7/212/3e30e721209cb7e432084d37bdd7828f.jpg
На рисунке выше видно, как алгоритм AFH скорректировал карту доступных для “перескакивания” каналов, исключив те, что попали в уже занятый вайфаем 6-й канал.


    1. Архитектура Bluetooth



Раз проблема была не в интерференции с Wi-Fi, то потребовалось более глубокое погружение в матчасть. Напомню, что интересным с точки зрения анализа был тот факт, что в одинаковых условиях две Bluetooth аудиосистемы (Klipsch KMC 3 и Edifier Spinnaker) вели себя по-разному. Klipsch захлебывался раньше, и для достижения эффекта нужно было просто заслонить телом прямой путь к колонке на расстоянии нескольких метров. Edifier же мог хрюкнуть пару раз, но после продолжал уверенно воспроизводить звук, изредка прерываясь.
Симптомы косвенно намекали на автоподстройку неких параметров со стороны Эдифаеров и отсутствие оной у Клипша при деградации качества радиосигнала. Чтобы проверить эту теорию, было решено снять дамп соединения двух устройств с целью поиска источника проблем.

Для чистоты эксперимента я выключил модуль Bluetooth, удалил из списка сопряженных устройств Klipsch, включил “синий зуб”, и, нажав кнопку записи дампа, прошел процедуру от поиска устройства и соединения с ним до передачи аудио.
Инициализация устройства

После активации Bluetooth-модуля, дамп наполняется записями сообщений HCI, которые в большинстве своем дают модулю понять, как его зовут, какой у него MAC адрес, к какому классу устройств он относится и включает непосредственно радио модуль.

Происходит это в форме диалога HCI Command -> HCI Event.

https://habrastorage.org/getpro/habr/post_images/234/479/090/234479090e943e574ec644228b1cec08.png
Стек блютуса лишь косвенно напоминает привычный TCP/IP, поэтому лицезрение дампа без предварительного прочтения спецификации не увенчалось успехом.

К чести группы Bluetooth SIG отмечу, что документация на корневую спецификацию и всевозможные профили находится в свободном доступе на портале для разработчиков, при этом написана простым и понятным языком.
https://habrastorage.org/getpro/habr/post_images/6d0/baa/544/6d0baa544476b537e527216846e54c66.png

Архитектура Bluetooth
Так моей настольной книгой на энное количество времени сталаBluetooth Core Specification. 13 мегабайтная пдф-ка о шести томах только сперва кажется необъятной, но для понимания базовых операций и принципов взаимодействия подсистем достаточно будет и нескольких глав.

Core System

В процессе поиска источника проблем я шел сверху вниз: встречая в дампе высокоуровневые протоколы, пытался понять логику их работы и назначение передаваемых параметров.

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

Ядро блютуса — Bluetooth Core System Specification — описывает четыре базовых нижних уровня архитектуры и соответствующие протоколы, причем три нижних уровня, как правило, выделяют в отдельную подсистему — Bluetooth Controller, а все, что находится выше — относится к Bluetooth Host.

Структурная схема архитектуры Bluetooth Core System показывает расположение основных блоков архитектуры на уровнях модели, обозначает user-plane и control-plane трафик между блоками и, самое главное, дает представление об иерархичности стека.

https://habrastorage.org/getpro/habr/post_images/491/cd4/953/491cd495382bbfe9991fcc46c56b61f0.jpg
На схеме не сделан акцент на очень важной части архитектуры — Host to Controller интерфейсе (HCI), обеспечивающем взаимодействие софтовой подсистемы Host с железной подсистемой Controller. Всё взаимодействие верхних уровней Bluetooth системы с ее аппаратной частью происходит через HCI-команды, инициируемые драйвером. Эти команды в дампе будут нам встречаться постоянно.

Пройдемся по основным блокам архитектуры, чтобы понять их основное назначение:
RF

Блок Radio (он же PHY), как и подобает резиденту физического уровня, занимается преобразованием битовой последовательности в радио сигналы. Вопросы модуляции, спектральных характеристик и физики процессов обеспечения битовой скорости — все это решается на нижнем уровне модели.

Baseband Layer = Link Controller + Baseband Manager + Device Manager

Уровень Baseband представлен в виде трех блоков, совместная задача которых состоит в управлении физическими каналами (Phy channels), поверх которых устанавливаются физические соединения (Phy links).  Bluetooth-адресация, синхронизации генераторов устройств, управление кодами доступа к физическим каналам, поиск устройств и установление физического канала между ними — все это задачи Baseband-уровня.
Link Manager

После того, как два нижних уровня обеспечили нас физическим соединением между master-slave устройствами, дело становится за организацией логических каналов, которые впоследствии и станут базой для передачи трафика приложений. Link Manager в ответе за установление, изменение и освобождение логических соединений между устройствами, а так же за обновление параметров физических соединений. Для этих целей Link Manager использует Link Management протокол (LMP).

L2CAP Layer = Channel Manager + L2CAP Resource Manager
Переваливаемся в высокоуровневый блок Bluetooth Host, оккупированный L2CAP уровнем. Logical Link Control and Adaptation Protocol (L2CAP) — протокол, работающий поверх созданных логических соединений, обеспечивающий инкапсуляцию, сегментацию и восстановление пакетных данных от всех вышележащих приложений.
Транспортная архитектура

В процессе знакомства с блоками архитектуры у вас уже могла выстроиться картина общей транспортной архитектуры Bluetooth, которая представляет собой трехуровневую модель:
https://habrastorage.org/getpro/habr/post_images/1ae/32b/8a5/1ae32b8a5013b9e981aaba5b48f3ecfa.png
В дальнейшем в тексте я буду использовать слово “каналы” для обозначения Channels и “соединения” для Links.
https://habrastorage.org/getpro/habr/post_images/cc4/0a5/b69/cc40a5b69816b532a5d94e527252bf48.png

На картинке выше представлен путь юникастного асинхронного трафика по транспортной архитектуре. Именно этот тип трафика характерен для передачи “пакетного” аудио.


SCO vs ACL

Если внимательно посмотреть на предыдущий рисунок, то на уровнях Logical Links и Logical Transports чаще всего встречаются аббревиатуры ACL и (e)SCO. Это два глобальных типа логических соединений между Bluetooth-устройствами, которые служат для передачи разного рода трафика вышестоящих приложений.

По ACL (Asynchronous Connection-Oriented Links) соединениям передается асинхронный, пакетный трафик с возможностью повторной отправки в случае потерь при доставке, сегментации и управления потоком.

SCO-соединения, в свою очередь, по сути организованы по принципу коммутации каналов с постоянной пропускной способностью 64кбит/с и синхронной передачей данных в тайм-слотах. SCO-каналы, например, используются профилем Headset для потоковой передачи голоса абонента от телефона к гарнитуре.

Согласно архитектуре Host Controller Interface, каждая его команда (HCI command) должна сопровождаться ответным событием (HCI Event). Ответ всегда возвращает статус команды (Success или код ошибки), а так же, опционально, запрошенные командой значения.

Ниже приведены три HCI команды на этапе самоинициализации модуля и события-ответы на них.
https://habrastorage.org/getpro/habr/post_images/09e/ae8/c5e/09eae8c5eda9179f3b883a2f67e4014c.png


Поиск и обнаружение устройств

После того, как Bluetooth собрал информацию “о себе”, я запустил поиск устройств. Когда вы зажимаете кнопку до состояния мигающего индикатора, устройство переводится в режим прослушивания канала обнаружения (Inquiry Channel). Когда девайс услышит код доступа “ответьте все” на этом канале, он отправит информацию о своем присутствии.

Как и любой процесс обращения верхних уровней к железной части Bluetooth, все начинается с команды от HCI:

https://habrastorage.org/getpro/habr/post_images/c3a/63d/e45/c3a63de45f8ef0e84519ec14c94b7033.png


Здесь интерес представляет поле LAP. На самом деле это ни что иное, как аналог мультикаст адреса (general access code), увидев который на канале обнаружения, Bluetooth-устройства обязательно оповестят о своем присутствии ответным сообщением.

В итоге все девайсы, получившие general access code на своем физическом канале для обнаружения, отвечают сообщениями Inquiry Response, в которых:
https://habrastorage.org/getpro/habr/post_images/51f/c15/ca1/51fc15ca164bc150300d937c71ae8023.png


указан MAC адрес устройства, его главный и второстепенные классы (Major Class и Minor Class), а также поддерживаемые сервисы.

Я выделил два параметра: первый — Sink — свидетельствует о том, что устройство может выступать в роли приемника аудиосигнала, а второй — Advanced Audio Distribution — что аппарат поддерживает тот самый A2DP-профиль.
Подключение

После процедуры поиска картина мира для Bluetooth-устройства становится ясна, самое время переходить к фазе подключения, или, как этот процесс называют в спецификации — Paging.

https://habrastorage.org/getpro/habr/post_images/652/ded/5e8/652ded5e8b54ca248de85c697ef9e090.png

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

Так как каждое Bluetooth-устройство оснащено своим собственным генератором, то ни о какой изначальной синхронизации между ними, естественно, речи не идет. Синхронизации добивается Link Controller в процессе установления соединения.

Происходит это следующим образом: в процессе поиска master-устройство получает от ответчиков среди прочих параметров еще и их значение тактового генератора. Затем, на этапе установления соединения master-устройство передает предполагаемое значение смещения тактового генератора для slave-устройства (параметр Clock Offset в скриншоте выше), тем самым ускоряя процесс синхронизации двух генераторов.

Самым важным полем команды Create Connection на подключение является идентификатор удаленного устройства — его Bluetooth-адрес (BD_ADDR). Вслед за командой контроллеру на установление соединения в бой вступает LMP протокол, который полностью управляет процессом организации логических соединений, поверх которых впоследствии будет гулять наш трафик:
https://habrastorage.org/getpro/habr/post_images/550/511/c52/550511c527ea8c3b70a3e8f4c04b0413.png
Если помните, в начале статьи я рассказывал о методе Adaptive Frequency Hopping, позволяющем избежать интерференции на уже занятых частотах? Так вот, карта используемых частот как раз и передается в LMP сообщении Set AFH. В процессе работы я замечал новые появления данных пакетов с другой картой частот, что свидетельствует о постепенном мониторинге эфира на предмет страдающих от интерференции каналов.

Итогом процесса установления соединения станет присвоение связи двух Bluetooth устройств идентификатора Connection Handle.

Сопряжение (Pairing)

Окей, мы установили физическое соединение с устройством, синхронизировали генераторы устройств и готовы к передачи служебной и пользовательской информации в тайм-слотах, чего не хватает? Спаривания. Наши устройства пока не доверяют друг другу, а значит никакой пользовательский трафик недопустим к передаче.
Т.к. оба устройства поддерживают версию спецификации Bluetooth 3.0, то им доступен метод аутентификации Secure Simple Pairing (и его подметод Just Works), позволяющий аутентифицировать и авторизовать устройства без ввода каких-либо пин-кодов.
L2CAP in action

В главе, посвященной транспортной архитектуре, изображена схема иерархии каналов и соединений, на вершине которой находится L2CAP-протокол. Именно его очередь и наступает сразу после процессов аутентификации устройств.

Структурная схема архитектурных блоков L2CAP-уровня повествует о его возможностях по сегментации, повторной отправке, управлению потоками и ресурсами.

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

Для того, чтобы от процедуры спаривания устройств перейти к непосредственно информационному обмену, хорошо бы знать, а какие профили поддерживает сопряженное устройство, умеет ли оно воспроизводить аудио или орагнизовывать обмен файлами? На эти вопросы отвечает протокол Service Discovery (SDP). Так как это протокол верхнего уровня, ему не обойтись без услуг L2CAP-протокола, который специально для этого создаст канал. Давайте посмотрим, как это происходит.

https://habrastorage.org/getpro/habr/post_images/64c/21f/9a1/64c21f9a197e6e41daf825d1c44b48db.png

В моем примере после успешного спаривания устройств появился первый L2CAP-пакет, содержащий следующие поля:
https://habrastorage.org/getpro/habr/post_images/36b/134/808/36b13480892db52f78bc52c26e2bf0ed.png
Команда Connection Request, как подсказывает КО, инициирует создание соединения с L2CAP уровнем slave-устройства, при этом в структуре пакета есть интересные для нас поля.

L2CAP протокол использует концепцию каналов, конечные точки такого канала в паре master-slave идентифицируются при помощи 2-байтного CID (Channel Identification). CID 0x0001 — зарезервированный идентификатор канала для терминирования трафика сигнализации L2CAP протокола, что логично, ведь именно к сообщениям сигнализации относится команда Connection Request (Channel ID: 0x0001 в нижней части скриншота).

Следующее важное поле — это PSM (Protocol/Service Multiplexer). Значение PSM говорит о том, для какого протокола или сервиса мы организовываем L2CAP канал и, как видите, речь идет о канале для Service Discovery Protocol.


Service Discovery

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

Происходит это в форме следующего диалога:

— умеешь ли ты “_какой-нибудь сервис_”?

— да, умею, и вот его характеристики (в противном случае ответ “нет, не умею, спрашивай далее”).

На запросы всех сервисов, кроме Audio Sink и AV Remote Controller я получил негативный ответ, а значит колонка, что логично, умеет только воспроизводить аудио и давать управляющие сигналы мастер устройству (например при нажатии на кнопку pause на колонке, на паузу устанавливается проигрывание у источника).

После того, как SDP узнал о собеседнике все, что мог, самое время переходить к непосредственной передаче аудио, за которую отвечает…

Audio/Video Distribution Transport Protocol
За организацию и управление аудио/видео потоками отвечает именно этот парень. И в моем случае разобраться в логике его работы можно было, даже не погружаясь в 160-страничную спецификацию.

Диаграмма работы AVDTP довольно понятна. Чтобы запустить поток, требуется открыть два канала: один управляющий (signalling) и один, непосредственно, для передаваемых аудио/видео данных.

https://habrastorage.org/getpro/habr/post_images/a5a/1a6/531/a5a1a65310367185d265ba158a4dcc77.png

Как мы уже знаем, никуда не деться от L2CAP, именно по его каналам сверху будет идти трафик AVDTP-протокола.
L2CAP канал в этом случае открывается с новым значением PSM, соответствующим протоколу AVDTP.

Один L2CAP канал открылся для сообщений сигнализации, второй для данных AVDTP, а третий для Audio/Video Control Transport Protocol (для передачи сигналов от колонки к источнику звука) инициировала колонка.

https://habrastorage.org/getpro/habr/post_images/d4a/762/6e1/d4a7626e1c4b8bb3ec53026ddf9cd65e.png

Обратите внимание на пары Source CID/Destination CID, это точки входа для L2CAP-каналов. Пара Src/Dst CID однозначно определяет L2CAP-канал.

После установления нужных L2CAP-каналов запустился процесс обмена служебными сообщениями между AVDTP-протоколами на обеих сторонах соединения. Среди служебных сообщений стоит отметить:



https://habrastorage.org/getpro/habr/post_images/32f/386/e2f/32f386e2f87c854483853c8c6d7ea594.png
Команда Discover позволяет узнать у удаленного устройства, а, собственно, что конкретно оно может предложить в рамках аудио/видео передачи. В ответ должно прийти описание возможностей в виде списка Service Endpoints (точек предоставления сервиса).

На первый взгляд непонятно, почему у колонки две точки в роли “приемник аудио”. На этот вопрос отвечает следующая пара сообщений:

https://habrastorage.org/getpro/habr/post_images/f69/c17/cea/f69c17ceaa28f8fb8239e11d42f7ebec.png
Обратите внимание на пару значений Min Bitpool и Max Bitpool, вскоре они сыграют важную роль.

https://habrastorage.org/getpro/habr/post_images/365/340/1fa/3653401fadf90f936f4e15c329bcf573.png

Так как Klipsch KMC3 умеет понимать два кодека — обязательный для A2DP-устройства SBC кодек и опциональный, проприетарный AptX кодек — то мы и видим две точки предоставления AVDTP-сервиса, они отличаются только типом поддерживаемого кодека, не более того.


AptX vs SBC
После получения сведений о возможностях сервисных точек AVDTP протокол сообщением Set Config выбирает работу с кодеком AptX.

Так было с Klipsch, но Edifier Spinnaker не поддерживает кодек AptX, поэтому его список сервисных точек состоял ровно из одной штуки с обязательным кодеком SBC (Low Complexity Subband Coding). В итоге дампы, снятые при установлении к двум системам, отличались лишь в выбранном кодеке передаваемого аудио!

Окей, но ведь AptX такой навороченный, платный, закрытый и пиарящийся на CeBITах, почему он, собака, начинает “замирать” в определенных условиях, и можно ли как-то заставить работать колонку Klipsch с SBC-кодеком, чтобы убедиться, что проблема именно в этом?

Для проверки я подключился к Edifier, повторил опыт с расположением ноутбука за своим телом во время записи дампа, и вот, что я увидел. Ниже представлен фрагмент AVDTP-протокола, содержащий в себе закодированный кодеком SBC фрагмент передаваемого аудио.
https://habrastorage.org/getpro/habr/post_images/4ea/6db/8f8/4ea6db8f8946ce756be3cc450a474dbf.png
Т.к. SBC — кодек открытый, то в дампе можно увидеть относящуюся к нему информацию, связанную с передаваемыми аудиоданными. В  спецификации A2DP подробно описана работа SBC-кодека, откуда можно выяснить, что одним из ключевых параметров, влияющих в итоге на качество кодирования, является значение bitpool.
Из дампа видно, что значение bitpool для данной порции трафика равно 48, но стоило мне закрыть телом путь от ноутбука до колонки, как значение bitpool стало снижаться, сопровождаясь прерываниями и щелчками.
После того, как значение bitpool устаканилось на уровне 30, щелчки пропали, проигрывание аудио стало вновь непрерывным. Все указывало на то, что кодек выполнил автоподстройку, заметив деградацию качества сигнала.

Но неужели я своим бренным телом вносил такое существенное затухание? Что ж, время взглянуть на график индикации уровня мощности принимаемого сигнала:

https://habrastorage.org/getpro/habr/post_images/eb6/fb6/7a8/eb6fb67a824a846b8b3f7c698214aac9.png
Хорошее тело, качественно вносит затухание, о которое и спотыкаются кодеки. Вот только SBC-кодек подстроился под эти условия, снизив качество кодирования, а тем самым и необходимую пропускную способность, а AptX, по-видимому, нет.

Чтобы окончательно убедиться в том, что виноват AptX, я отключил его поддержку в Mac OS X и снова стал домогаться до Klipsch. Теперь был согласован кодек SBC между макбуком и колонкой, т.к. AptX’а ноутбук был принудительно лишен. Стоит ли говорить, что с SBC-кодеком Klipsch перестал так сильно заикаться в условиях падения уровня мощности сигнала?

Долго ли коротко, но проблема диагностирована, и ввиду закрытости AptX у меня не было никаких шансов повлиять на работу кодека (как это можно сделать с SBC, задав вилку значений bitpool в OS X). Поэтому осталось лишь не маячить телесами на пути видимого сигнала или использовать трюк с отключением кодека AptX в макоси.

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



  1. Поделитесь с Вашими друзьями:
1   2   3   4   5   6


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал