Відмінності між версіями «Установка з'єднання в Bluetooth»

Версія за 08:10, 30 вересня 2010

Цей розділ описує основні процедури, які повинні бути виконані пристроями Bluetooth, щоб встановити між ними з'єднання. Розгляньте наступний сценарій: чоловік гуляє з готелю і хоче скористатися своєю електронною поштою за допомогою пристрою Bluetooth, яким може бути ноутбук або PDA. Що він мав би зробити? Він натиснув би на меню або піктограму поштової програми. Пристрій автоматично виконав б наступні кроки (крім кроку реєстрації, актуального в разі, якщо пристрій вперше використовується в цьому середовищі):

1. Запит: пристрій при вступі в нове середовище автоматично ініціалізувати б запит, щоб з'ясувати, які пристрої є доступними в межах його радіуса дії. Це приведе до наступного:

а) Всі доступні прилеглі пристрої дадуть відповідь.

б) Пристрій вибирає одне з відповіли пристроїв.

2. Пейджинг: пристрій викличе baseband-процедуру, звану пейджинг. У результаті відбувається синхронізація пристрою з пунктом доступу, серед інших необхідних ініціалізації.

3. Встановлення з'єднання: LMP встановить з'єднання з точкою доступу. Оскільки додаток в цьому випадку поштове (email), буде використовуватися ACL з'єднання.

Далі будуть виконуватися нижченаведені дії по встановленню.

4. Сервіс: LMP буде використовувати протокол SDP для встановлення, який сервіс є доступним, зокрема, поштовий сервіс, або потрібно звернеться до іншого хосту. Припустимо, що сервіс є доступним, інакше програма не може далі діяти. Інформація щодо інших сервісних послуг може бути також представлена користувачеві.

5. Канал L2CAP: На основі інформації, отриманої від SDP, пристрій створить канал L2CAP до пункту доступу. Він може використовуватися безпосередньо додатком або іншим протоколом, наприклад, RFCOMM.

6. Канал RFCOMM: В залежності від потреби поштового програми RFCOMM або інший канал (у випадку інших додатків) буде створено згідно з L2CAP каналу. Ця можливість дозволяє використовувати додатки, розроблені для послідовних портів, щоб працювати без модифікації по Bluetooth-платформ.

7. Безпека: Якщо пункт доступу обмежує доступ понад певної кількості користувачів або пропонує безпечне з'єднання режиму людям, які зареєструвалися раніше, тоді пункт доступу пошле запит безпеки при встановленні з'єднання. Користувач повинен знати правильний PIN-код для доступу до сервісу. Зверніть увагу, що PIN-код не передається по бездротовому каналу, використовується інший код, що згенерував з нього, тому PIN-код досить складно підібрати. При використанні безпечного режиму буде вироблено кодування передачі.

8. PPP: Оскільки PPP-з'єднання використовується з послідовного модему як при dial-up, те ж саме додаток зможе тепер запустити PPP через RFCOMM (через емульованого послідовний порт). Ця з'єднання дозволить користувачеві отримати доступ до його поштової скриньки тощо.

9. Мережеві протоколи: Мережеві протоколи типу TCP / IP, IPX, Appletalk можуть одержувати і передавати дані по каналу без труднощів.

В описаних вище процедурах для користувача взаємодія потрібна тільки при використанні логіна для входу в систему для електронної пошти і для додаткового захисту, яка буде здійснена. Решта кроки автоматичні. Вищезазначені процедури описані докладно, щоб продемонструвати процес встановлення підключення. Пояснення вищезазначених процедур потребує короткого опису пристрою годин на Bluetooth.

Годинник: Кожен Bluetooth модуль має вбудовану систему часу, яка визначає час і частотні передачі. Годинники Bluetooth є вільно йдуть часасмі, які ніколи не коригуються і ніколи не вимикаються. Для синхронізації з іншими модулями використовуються тільки зміщення (величина, на яку відрізняється час в інших модулях в порівнянні з "рідними" годинником), накладене на "рідні" годинник, - тимчасові годинник Bluetooth, які взаємно синхронізовані. Годинники Bluetooth не мають ніякого відношення до часу доби. Годинники Bluetooth дуже важливі для трансівера Bluetooth через синхронізації безлічі важливих подій, без яких неможлива зв'язок. Одиниця часу - принаймні половина TX або RX довжини слота, або 312.5 мікросекунд. Годинники мають денний цикл. Якщо годинник обладнані лічильником, 28-бітний лічильник вимагає обороти близько 228 1. LSB відраховує кванти по 312.5 мікросекунд, задаючи тактову частоту 3.2 КГц.

Синхронізація і частота на каналі piconet визначені Bluetooth-годинами "майстра". Коли мережа piconet сформувалася, відлік годин "майстри" передається на підпорядковані пристрої. Вони зберігають необхідне значення зміщення, яке потрібно використовувати при з'єднанні з даними "майстром" і використовуються для синхронізації каналу. Оскільки власні тимчасові координати (години) не змінюються, то можливо використовувати різні зміщення для реєстрації в різних мережах piconet.

Мінімальна необхідна точність годин -/-20 ppm в активному режимі, і/-250ppm в режимі малої активності, наприклад, Hold, Sniff, Standby і Park.

Запит та пейджинг

Це початкові кроки в процесі встановлення з'єднання.

Пристрій знаходиться в режимі Standby за замовчуванням. У цьому стані йдуть тільки рідні годинник і споживана потужність дуже низька. Можна вийти з цього режиму і увійти в режими Inquiry, Inquiry Scan, Page або Page Scan. Ці режими описані нижче:

Запит (Inquiry)

У цьому режимі пристрій посилає запит, адресований General Inquiry Access tt (GIAC) або Dedicated Inquiry Access tt (DIAC), який відноситься до спеціального класу пристроїв, скажімо, принтерів. Передача повторюється на 16 частотах, що й формує послідовність запиту, звану "поїздом" (train). Пристрій, що дозволяє запит, буде прослуховуватися на одній з цих частот. Передача виконується у кожному додатковому слоті, проміжні слоти використовуються для прослуховування відповідей. Існують два типи поїздів - A і B. Кожен потяг повинен бути повторений 256 разів, щоб зібрати всі відповіді в середовищі, вільної від помилок. Загальний час, необхідне для виконання - 10.24 секунд. Однак, якщо за менший інтервал зібрано достатньо відповідей, запит може бути перерваний. Якщо процедура запиту ініціалізується автоматично, один раз кожну хвилину, тоді інтервал між послідовними запитами повинен бути випадковим, щоб уникнути синхронізації і, отже, колізії з іншим пристроєм, залученим до запиту.

Перегляд / сканування запиту (Inquiry Scan)

Пристрій, який дозволяє собі бути виявленим, буде періодично входити в режим перегляду запитів і прослуховувати запити в окремій частоті, яку вибере з 16 частот у послідовності запиту, в залежності від адреси пристрою. Воно залишається в цьому режимі досить довго для пристрою запиту, щоб охопити 16 різних частот. Пристрій може входити в режим перегляду запиту з режиму з'єднання або очікування; якщо з режиму з'єднання, то SCO з'єднання в операції будуть підтримуватися, в той час як ACL з'єднання будуть припинені. Присутність SCO з'єднання може продовжити процедури запиту.

Відповідь на запит (Inquiry Response)

Коли повідомлення запиту отримано в режимі перегляду запиту, повинен бути надіслана відповідь, що містить адресу відповідає пристрою. Проте він не надсилається відразу ж наступним слотом після слота, в якому отриманий запит, оскільки це може змусити багато пристроїв, прослуховуються в даній частоті, відповідати одночасно, що приведе до зіткнення. Тому що відповідає пристрій чекає деяке число слотів і тоді посилає пакет FHS опитувач. Пакет FHS містить адресу пристрою; його годинник і інформація про те, коли пристрій входить в режим перегляду сторінки. Після відповіді на запит пристрій продовжує перегляд запиту на іншій частоті, без очікування підтвердження.

Запитуючий пристрій при отриманні не підтверджує відповідь, але продовжує процедуру запиту. Тільки коли запитуючій пристрою потрібно встановити обмін даними із запитуваною пристроєм ("paging") у наступний час, воно буде використовувати отриману раніше від запитуваної пристрою у відповідь на свій запит інформацію.

Після того, як запит був успішно виконаний, або адресу пристрою, з яким має бути встановлене з'єднання, було визначено іншими засобами, пристрій запустить процедуру пейджинга. Пейджинг запрошувати не тільки адресу пристрою, який потрібно переглянути, але інформацію про часових координатах; для прискорення процедури може використовуватися FHS. Пристрій, що запускає процедуру пейджинга, називається master `ом, і це буде master мережі piconet, що складається з нього і переглядається пристрою, якщо переглядається пристрій приймає з'єднання. Однак перед стартовою передачею даних пристрої можуть помінятися ролями. Ця процедура зазвичай відбувається щоразу, коли пристрій Bluetooth потрапляє в нове середовище або деякі старі з'єднання стали недоступними. Після виклику програми, пристрій запустить процедури пейджинга.

Пейджинг

Цей режим вимагає від master `а виконати наступне:

1. Пристрій "master" використовує інформацію про часових координатах підлеглого пристрою, якщо така є, щоб визначити, де в послідовності запитів "slave" міг би прослуховуватися в режимі сканування. Ця оцінка може бути повністю неправильна.

2. Майстер обчислює код доступу пристрої slave (Device Access tt / DAC /) з адреси пристрою, вже використовує певну процедуру.

3. "Master" посилає пейджинг-повідомлення, поїзд А включає в себе ці 16 частот, що оточують частоту, а потяг B - решта. Якщо поїзд А неуспешен, поїзд B так само пробує декілька процедур пейджинга. Якщо поїзд А успішний, процедура пейджинга буде закінчена через 1.28 секунд; інакше процес займає 2.56 секунд.

Перегляд / сканування пейджинга

Режим сканування пейджинга може бути введений з режиму standby або режиму з'єднання. У цьому режимі "slave" прослуховує пакунки пейджинга, адресовані його DAC для інтервалу Tw page scan в частоті, яку вибирає з послідовності перегляду пейджинга. Це вікно досить довге для охоплення 16 перельотів частоти пристрої пейджинга. Періоди прослуховування розділені інтервалом часу Tpage scan. Цей інтервал може бути нульовим (продовження сканування). Встановлено три різних режими сканування зі значеннями Tpage scan. Пристрій "slave" може використовувати інші значення після повідомлення master `а. Таким чином, для першого з'єднання використовується одне із стандартних значень.

Відповідь пейджинга

При отриманні повідомлення пейджинга "slave" входить в режим відповіді пейджинга: посилає тому відповідь пейджинга, що складається з ID пакету, який містить його DAC, в частоті для наступного слота після того, в якому було отримано повідомлення пейджинга. "Мaster" при отриманні цього пакету входить в головний режим відповіді пейджинга. "Мaster" посилає FHS пакет пристрою "slave", повідомивши йому свої координати часу, все ще використовуючи DAC пристрої "slave" в його частоті прослуховування. "Slave" підтверджує цей пакет, відправляючи знову ID пакет у своїй частоті відповіді. "Slave" тепер використовує пакет FHS, отриманий від "master` a ", щоб визначити код доступу до каналу для недавно сформованої мережі piconet, або тієї, в яку увійшло пристрій недавно. Також обчислюється зсув годин, яке потрібно використовувати при з'єднанні з piconet. Наступний пакет від "master" `a до" slave ", який є пакетом опитування, адресованим адресою активного" slave ", використовує код доступу до каналу. "Slave" може відповісти на цей пакет будь-яким пакетом, може навіть відправити нульової пакет (який містить лише заголовок каналу), але і це буде відповіддю. Якщо процедура відповіді пройшла успішна, пейджинг закінчено, і пристрій "slave" знаходиться в стані з'єднання.

Таблиця: Зміни початкового повідомлення протягом запуску.

Після того, як процедура пейджинга перейде в стан з'єднання, пристрої можуть встановлювати з'єднання. Менеджери зв'язку пристроїв у стані з'єднання обмінюються інформацією для запуску з'єднання, яка буде описана нижче.

Модулі Bluetooth можуть бути в декількох режимах роботи в стан з'єднання: активний режим, режим "sniff", режим "hold" і режим "park".

Активний режим

У цьому режимі модель Bluetooth активно бере участь на каналі. Пристрої "master" і "slave" здійснюють передачу по альтернативним слотів, "master" - по всіх парних пронумерованим слотів, "slave" передає в подальшому слоті. Правильні передачі зроблені "master` ом ", щоб зберегти синхронізацію пристроїв" slave "на каналі. З метою енергозбереження забезпечуються різні оптимізації. Наприклад, якщо "master" повідомляє пристрою час адресації, "slave" до цього моменту може не діяти. "Master" для передачі опитує активні пристрої.

Режим Sniff

Це режим низької потужності, в якому прослуховуються діяльність пристрої "slave" зменшена. LMP "master` а "дає команду пристрою для входу в режим Sniff, що дає інтервал Tsniff, зміщення Dsniff, і кількість спроб Nsniff. У режимі sniff "slave" прослуховує передачі тільки на фіксованому інтервалі Tsniff, на слоті Dsniff Nsniff разів.

Режим Hold

У цьому режимі ACL зв'язок c пристроєм "slave" в режимі підтримується hold. Це означає, що "slave" тимчасово не підтримує пакети ACL на каналі (можливо, будуть все ще підтримуватися SCO-зв'язку). У режимі hold може з'явитися здатність займатися іншими процесами, наприклад, скануванням, пейджинг, запитами або відвідинами другий piconet. Модуль у режимі hold може також входити в "сплячий" режим з низьким енергоспоживанням. Протягом режиму hold, модуль "slave" зберігає активний адресу (AM_ADDR). "Мaster" і "slave" погодять тривалість інтервалу hold, після якого "slave" виходить із режиму hold.

Режим Park

Це режим з дуже невеликим споживанням енергії. Пристрій "slave" мало активно в цьому режимі. Він привласнює своєму активному члену адреса: закріплений адресу (восьмібітний) і адреса запиту доступу (восьмібітний). "Master" може використовувати закріплений адресу члена для "розпакування", відкріплення пристрої "slave", в той час як "slave" для опитування "master` a "про розпакуванні використовує адресу запиту доступу. Проте пристрій "slave" залишається синхронізованим на канал. Будь-які повідомлення для передачі закріпленому пристрою будуть надіслані широкодіапазонним каналу. Закріплене пристрій повинен бути проінформована про цю передачу по каналу, який підтримується "master` ом "для продовження закріплення," паркування ". Закріплені пристрої регулярно прослуховуються для сигналів в інтервалах, визначених структурою маяка, повідомленої пристрою на початку закріплення. Крім енергозбереження режим допомагає пристрою "master" з'єднуватися більш як із сімома пристроями (обмежена активним адресним простором члена в три біти) у piconet.

Встановлення зв'язку

Як тільки пристрій буде перебувати в стані зв'язку, LMP може починати встановлювати з'єднання. З'єднання L2CAP базуються на концепції каналів, які визначаються ідентифікаторами каналу, аналогічними сокетами в TCP / IP. Канал, відмінний від каналу piconet, ідентифікується адресою пристрою, з яким створено двосторонню з'єднання, і ідентифікатором каналу. Основні кроки в установці з'єднання в підсумку виглядають так:

1. Пакети POLL і відповідь використовуються для передачі інформації конфігурації без взаємодії хоста.

2. Відправляється пакет LMP_host_connect_request.

3. Віддалене пристрій відповідає LMP_NOT_ACCEPTED, якщо додаток, запитувана першим пристроєм, не хоче або не може відповісти. Інакше надсилається відповідь LMP_ACCEPTED.

4. Відповідає пристрій може запитати про відключення ролі, якщо це буде потрібно з деяких причин. Перший пристрій відповідає відповідним пакетом для прийняття або не прийняття запиту.

З'єднання встановлено на рівні Link Manager.

Додаток може не бути поінформоване про те, які послуги є доступними, і буде використовувати SDP, щоб це виявити.

SDP

Зміни середовища Bluetooth відбуваються часто, отже, доступні послуги повинні бути виявлені в полі зору. SDP забезпечує кошти програми для виявлення, які сервіси є доступними, і їх характеристики, як описано в основних специфікаціях. Пристрій Bluetooth, послуги якого повинні бути виявлені, запускає SDP сервер. Для виявлення послуг інших пристроїв запускає SDP клієнта. Один клієнт може запущено для кожної програми, але один пристрій може запустити тільки один сервер SDP. Сервер SDP обслуговує сервісну запис кожної служби, що дозволяє пристрою виявлятися. Клієнт надсилає запит на сервер. Запит може бути пошуком специфічного класу сервісних послуг або переглядом всіх класів доступних сервісів. Сервер дає відповідний відповідь. Якщо пристрій сервера має тільки декілька сервісів, вони не можуть бути розділені на класи та сервісні опису не відправляються пристрою. В іншому варіанті опису класу відправляються і клієнт може продовжувати вивчати деталі в межах класу. SDP тільки дозволяє сервісів бути виявленими. Доступ повинен бути через інші протоколи, засновані на L2CAP. L2CAP з'єднання Інформація, отримана через LMP з'єднання і через SDP, буде використовуватися L2CAP, щоб встановити канал для програми. L2CAP встановлює лише зв'язку ACL з'єднання. З'єднання L2CAP базуються на концепції каналів, які визначаються ідентифікаторами каналу, аналогічними роз'ємів в IP TCP. Канал, відмінний від каналу piconet, ідентифікується адресою пристрою, до якого створено з'єднання, і ідентифікатором каналу. Кожен канал приймається до заповнення дуплексу, з QoS специфікацією в кожному напрямку. Канал може бути двухточечной або багатоточковий. L2CAP встановлює з'єднання, коли на нього додатком виражений запит і з'єднання на потрібний пристрій ще не було встановлено. Запити від нижніх рівнів щодо з'єднань, необхідних програмами на віддалених пристроях, також обробляються L2CAP відповідно до залученим додатком.

SCO з'єднання не проходять по L2CAP, але посилають їх дані безпосередньо Baseband. L2CAP встановлює окремий сигнальний канал для запиту з'єднання, конфігурації, роз'єднання і пр. (для випробування). L2CAP-пакети не забезпечують CRC або інші перевірки помилок, покладаючись на смугу baseband для захисту даних і впорядкованої доставки.

Взаємодія цього протоколу з верхніми і нижніми рівнями розглядається в подіях і діях. Події - всі повідомлення, отримані L2CAP від більш низьких або більш високих рівнів, у той час як дії - відповіді, зроблені для них. Нижнім рівнем може бути LMP або HCI, в той час як більш високим рівнем може бути будь-який додаток. Типова послідовність подій і дій для встановлення з'єднання може бути наступна:

1. Подія і Дія 0: Подія - це запит з'єднання від більш високого рівня. Дія полягає в тому, що пристрій L2CAP посилає пакет запиту віддаленого L2CAP. Цей пакет на віддалене пристрій доставляє baseband.

2. Подія і Дія 1: Віддалений L2CAP отримує цей пакет і відповідає з пакетом у відповідь підключення. Перед виконанням L2CAP контактує з віднесеним додатком, щоб перевірити, чи буде потрібний запит фактично оброблено тим додатком.

3. Подія і Дія 2: Прийом у відповідь пакету - подія для локального пристрою L2CAP. Взаємодія запрошувати про параметри конфігурації: максимальний модуль payload і межі часу очікування.

4. Подія і Дія 3: Запит конфігурації - подія для віддаленого L2CAP. Його дія - відповідь конфігурації. Також, можна посилати його власної конфігурації запит про додаткові параметри.

5. Подія і Дія 4: Вищезгаданий пакет - подія для місцевого пристрою. Воно відповідає з відповіддю конфігурації.

Ініціатором в місцевому пристрої виступає L2CAP, адресатом - L2CAP в пункті доступу або іншому пристрої Bluetooth, з яким входить у контакт. Зверніть увагу, що за вказаним на стрілках, що вказують до ініціатора або адресату - події для L2CAP, в той час як стрілки, що вказують за межі - дії. Назви, що починаються з L2CAP, є з'єднаннями між двома L2CAP на різних пристроях. Вертикальні рядки LP - Менеджери Зв'язки в цих двох пристроях. Назви, що починаються з WA, представляють собою з'єднання з додатком більш високого рівня, для якого встановлюється канал.

Стану OPEN відзначають інтервал з'єднання додатків. Останні кроки у вищезгаданій таблиці відносяться до роз'єднання. Тепер можуть бути передані дані програми або можуть бути виконані процедури захисту, які коротко описані в наступному підрозділі.

Захист

Ймовірно, що повідомляються дані доведеться зашифрувати або доведеться обмежити доступ до пристрою, забезпечуючи розпізнавальну процедуру. Ці функції забезпечуються рівнем baseband. Додаток може самостійно зашифрувати дані для посилення захисту. Ці процедури використовують чотири значення: адреса пристрою (який є громадським), приватний розпізнавальний код кодування (на 128 бітів), приватний ключ (8-128 бітів, з перебудовується конфігурацією) і випадкове число. Оскільки коди повинні бути секретними, вони не можуть бути отримані відповідно до запиту. Складні процедури для генерації, управління та обміну кодами секретності описується в розділі Система безпеки. Процедура захисту вимагає, щоб секретний PIN-код був відомий користувачу (або збережений його додатком) для звернення до специфічного пристрою. Основні кроки:

1. Розпізнавальний код створюється з PIN-коду, довжини PIN-коду, випадкового числа і адреси пристрою. Залежність від адреси пристрою створює определеннние труднощі для шахрайського пристрою, адже доведеться пробувати велика кількість PIN-кодів, оскільки кожний повинен бути перевірений різними адресами пристрою.

2. Щитки процедура виходить з використання схеми відповіді дзвінка. Модуль верифікатори посилає випадкове число, згенерованої певним процесом для ідентифікації. Це випадкове число таке, що пристрій претендента, яке має правильний код ініціалізації (або код зв'язку, якщо пристрої провели обмін протягом більш раннього з'єднання) і необхідного адреси пристрою, зможе призвести номер відповіді, який відомий верифікатори. Цей номер відповіді відправляється назад і перевіряється верифікаторів.

3. Претендент може також виконувати перевірку на верифікатори, використовуючи подібну процедуру, описану вище.

4. Кожен модуль Bluetooth має код, встановлений в енергонезалежній пам'яті. Пристрій використовує код ініціалізації, щоб зашифрувати цей код і відправити іншого пристрою, яке розшифровує його, використовуючи код ініціалізації, отриманий раніше при обміні.

5. Друге пристрій може додавати свій власний код модуля до коду модуля першого пристрою і генерувати об'єднаний код зв'язку, якщо обидва пристрої здатні до його обробці. Інакше код модуля одного з пристроїв обробляється як код зв'язку. Код зв'язку повідомляється на перший пристрій. Код зв'язку попрощався.

6. Ключ кодування створюється з коду зв'язку, випадкового числа і іншого числа, отриманого з встановленої процедури. Обидва пристрої можуть генерувати ключ кодування, так як вся необхідна інформація відома обом пристроїв. Цей код використовується для кодування payload даних.

Код зв'язку запам'ятав. Якщо між цими двома пристроями в більш пізній час має бути встановлено інше з'єднання, може використовуватися безпосередньо цей код зв'язку. Це усуває потребу знову посилати код по каналу. Таким чином, дані можуть бути надійно передані з мінімальним користувальницьким взаємодією.

Зв'язок додатків

Прикладні дані будуть тепер передані через з'єднання, оскільки всі визначені процедури встановлення з'єднання Bluetooth були виконані. Додатка необхідно запустити протокол більш високого рівня L2CAP. Bluetooth було визначено три використовуваних протоколу. Це:

RFCOMM

Це емуляція послідовного порту через бездротове з'єднання.

SDP

Це Service Discovery Protocol, який допомагає пристроям виявити доступні послуги поблизу.

TCS

Це Telephony Control Protocol Specification, описує управління запитом і передачу сигналів голосових каналів через Bluetooth. Всі користувальницькі додатки і інші існуючі механізми доступу до мережі, наприклад, IP TCP, PPP, IrDA OBEX, WAP і HomeRF можуть бути здійснені за рівнем L2CAP або вищезазначеним трьом протоколами, якщо додаток вибере використання їхніх послуг.

Додаток в результаті повідомить, що більше не потрібно підключення, якщо воно не було зафіксовано протягом часу запуску програми. LMP посилає пакет LMP_detach пакет на віддалене пристрій, на який не потрібно відповідь. Відбувається роз'єднання.

Технологія Bluetooth