Материал: конспект-лекций

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

Вказівка періоду перевірки доступності з'єднання

 

 

 

Источник: https://studfile.net/preview/16436030/