261
У кожної пікомережі діє тільки один провідний пристрій, однак ведені пристрої можуть входити в різні пікомережі. Крім того, провідний пристрій однієї пікомережі може бути веденим в іншій (рис. 2.13).
M |
S |
a) |
|
|
M |
S |
S |
|
S |
b) |
|
|
S |
|
M |
|
S |
M S |
|
|
M |
c)S
Рисунок 2.13 – Пікомережа із одним підлеглим пристроєм (а), декількома (b) і розподілена мережа (с)
В одній пікомережі всі пристрої синхронізовані за часом і частотами, у той час, як самі пі-
комережі не синхронізовані одна з одною за часом і частотою - кожна з них використовує свою послідовність частотних стрибків (FHS - Frequency Hopping Sequence). Послідовність частотних стрибків являє собою послідовність довжиною 512 елементів, елементом послідовності є номер каналу в діапазоні від 1 до 79. Номера каналів у послідовності розподілені за рівномірним зако-
ном. Дві й більше пікомереж, що працюють у зоні дії одна одної мають певну ймовірність збігу номерів каналів у своїх послідовностях у певний момент часу, такий збіг приведе до колізії. Гра-
фік залежності ймовірності колізії від кількості одночасно працюючих пікомереж представлений на рис. 2.14
262
Pcol
1 
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
00 |
|
|
|
|
|
|
|
|
|
n |
50 |
100 |
150 |
200 |
250 |
300 |
350 |
400 |
450 |
500 |
Рисунок 2.14 - Графік залежності ймовірності колізії від кількості пікомереж
Декілька пікомереж, здатних взаємодіяти одна з одною, формують розподілену мережу
(Scatternet) (рис. 2.15). У такій мережі один пристрій є прикордонним (Bridge Device) і працює від-
разу у двох сусідніх пікомережах, поперемінно перебудовуючись на різні схеми стрибків для кож-
ної з пікомереж.
Рисунок 2.15 - Пікомережи й розподілена мережа BLUETOOTH
Взаємодія з мережами інших стандартів. Протоколи, реалізовані в Bluetooth. Взаємодія з мережами інших стандартів (GSM, ISDN POTS) будується на стеці протоколів Bluetooth (рис. 2.16). Протоколи фізичного рівня, описані вище, представлені в блоці Baseband, і реалізуються апаратно.
263
Рисунок 2.16 – Стек протоколів Bluetooth
Протокол L2CAP (Logical Link Control and Adaptation Protocol) - основний протокол кана-
льного рівня в стеці протоколів Bluetooth. В L2CAP кадр інкапсулюються дані протоколів і профі-
лів верхніх рівнів. Два пристрої з підтримкою Bluetooth можуть установити декілька L2CAP з'єд-
нань для різних профілів. Наприклад, мобільний телефон може бути з'єднаний з ноутбуком з ви-
користанням профілю DUN для підключення до Інтернет і профілю SYNCH для синхронізації ад-
ресної книги в телефоні й ноутбуці. У цьому випадку для кожного профілю встановлюється окре-
ме L2CAP з'єднання. Формат базового кадру L2CAP (В-frame) представлений на рис. 2.17.
Рисунок 2.17 – Формат базового кадру L2CAP
Використання базових кадрів не забезпечує перевірки цілісності інформації й функцій по-
вторної передачі. Для забезпечення цих функцій використовуються інформаційні (I-frame) кадри й кадри супервізора (S-frame), їх формат представлений на рис.2.18.
264
Рисунок 2.18 – Формат кадру супервізора й інформаційного кадру L2CAP
S-кадри служать для підтвердження доставки й запиту повторного пересилання I-кадрів.
Кадри містять наступні поля (довжина полів у бітах зазначена на ілюстраціях):
Поле Length - довжина кадру в байтах;
Channel ID - ідентифікатор каналу, може приймати наступні значення:
0x0000 Null identifier - нульовий ідентифікатор;
0x0001 Signaling channel - канал сигналізації;
0x0002 Connectionless reception channel - канал без установлення з'єднання;
0x0003-0x003F Reserved - зарезервовані ідентифікатори каналів;
0x0040-0xFFFF Dynamically allocated - динамічно призначувані ідентифікатори.
Control - інформація про сегментацію даних, номері переданого й останнього підтвердже-
ного сегмента;
Information payload - дані протоколів верхніх рівнів;
FCS (Frame Control Sequence) - послідовність перевірки цілісності кадру, формується за до-
помогою циклічного коду CRC-16.
Протокол управління з'єднанням (LMP-Link Management Protocol) - основний протокол си-
гналізації стека Bluetooth, він заснований на командах управління, що передаються через інтер-
фейс взаємодії самого пристрою з Bluetooth-модулем (HCI - Host Controller Interface). З викорис-
танням цього протоколу виконуються функції встановлення й розриву з'єднання, процедури ауте-
нтифікації й шифрування, також виконується узгодження типів пакетів, що використовуються при обміні інформаціею. Приклади команд LMP представлені в таблиці 2.5 [1].
265
Таблиця 2.5 - Приклади команд протоколу LMP
Повідомлення |
Код |
Призначення |
|
операції |
|||
|
|
||
|
|
|
|
LMP_accepted |
3 |
Підтвердження розпізнаного повідомлення LMP |
|
|
|
|
|
LMP_not_accepted |
4 |
Підтвердження прийому нерозпізнаного повідомлення |
|
|
LMP |
||
|
|
||
|
|
|
|
LMP_clkoffset_req |
5 |
Запит зсуву значень таймерів синхронізації пристроїв |
|
|
|
Bluetooth |
|
LMP_clkoffset_res |
6 |
||
|
|
|
|
LMP_comb_key |
9 |
Зміна загального ключа, що використовується для проце- |
|
|
дури аутентифікації |
||
|
|
||
|
|
|
|
LMP_unit_key |
10 |
|
|
|
|
|
|
LMP_detach |
7 |
Роз'єднання з'єднання |
|
|
|
|
|
LMP features_req |
39 |
Запит списку реалізованих можливостей (профілів, що |
|
|
|
підтримуються) |
|
LMP_features_res |
40 |
||
|
|
|
|
LMP_host_connection_re |
51 |
|
|
q |
Установлення з'єднання |
||
|
|||
|
|
|
|
LMP_setup_complete |
49 |
|
|
|
|
|
|
LMP_max_slot |
45 |
Вказівка розміру багатослотового пакета |
|
|
|
||
LMP_max_slot_req |
46 |
||
|
|||
|
|
|
|
LMP_name_req |
1 |
Запит мнемонічного імені пристрою Bluetooth |
|
|
|
||
LMP_name_res |
2 |
||
|
|||
|
|
|
|
LMP_quality_of_service |
41 |
Запит інформації про якість обслуговування, що визначає |
|
|
|
||
LMP_quality_of_service_r |
|
||
42 |
інтервал передачі пакетів з інформацією |
||
eq |
|||
|
|
||
|
|
|
|
LMP_in_rand |
8 |
|
|
|
|
Обмін інформацією аутентифікації на основі загального |
|
LMP_au_rand |
11 |
||
ключа |
|||
|
|
||
LMP_sres |
12 |
||
|
|||
|
|
|
|
LMP_supervision_timeout |
55 |
Вказівка періоду перевірки доступності з'єднання |
|
|
|
|