Тема 1.

Загальні положення Інтернету речей

1.1. Вступ
1.2. Класифікація технологій передачі даних в IoT
1.3. Стандартизація IoT
1.4. Термінологія Інтернету речей

1.1. ВСТУП
Ідея Інтернету речей сама по собі дуже проста. Уявімо, що всі навколишні
нас предмети і пристрої (домашні прилади і посуд, одяг, продукти, автомобілі,
промислове обладнання та ін.) Забезпечені мініатюрними ідентифікаційними і
сенсорними (чутливими) пристроями. Тоді при наявності необхідних каналів зв'язку
з ними можна не тільки відслідковувати ці об'єкти і їх параметри в просторі і в часі,
а й управляти ними, а також включати інформацію про них в загальну «розумну
планету». У найзагальнішому вигляді з інфокомунікаційної точки зору Інтернет
речей можна записати у вигляді такої символічної формули:
IoT = Сенсори (датчики) + Дані + Мережі + Послуги.
Простіше кажучи, Інтернет речей - це глобальна мережа комп'ютерів,
датчиків (сенсорів) і виконавчих пристроїв, що зв'язуються між собою з
використанням інтернет протоколу IP (Internet Protocol). Наприклад, для вирішення
певної задачі комп'ютер зв'язується через публічний інтернет з невеликим
пристроєм, до якого підключений відповідний датчик (наприклад, температури), як
це показано на рисунку 1.1

Рис.1.1. Організація мережі Інтернету речей

Очевидно, що при впровадженні Інтернету речей все нашеповсякденне

життя кардинально зміниться. Підуть в минуле пошуки потрібних речей, дефіцити
товарів або їх перевиробництво, крадіжки автомобілів і мобільних телефонів,
оскільки буде точно відомо, що, в якому місці і в якій кількості знаходиться,
виробляється і споживається. Якщо всі об'єкти (речі) будуть забезпечені
мініатюрними радіомітками, то їх можна буде дистанційно ідентифікувати, а при
наявності певного «інтелекту» - і управляти ними. За оцінками експертів компанії
Cisco кількість об'єктів, які Інтернет речей зможе з'єднати між собою, буде порівняно
з кількістю атомів на поверхні Землі.
Концепція IoT відіграє визначальну роль у подальшому розвитку
інфокомунікаційної галузі. Це підтверджується як позицією Міжнародного союзу
електрозв'язку (МСЕ) і Європейського Союзу в даному питанні, так і включенням
Інтернету речей в перелік проривних технологій в США, Китаї та інших країнах. І
хоча на міжнародному рівні дана концепція вже набуває рис сформувалася
технології, для неї ведуться активні роботи в області стандартизації архітектури,
технічних компонентів, додатків, але одночасно настільки ж велике кількість думок
про те, як саме буде побудований Інтернет речей.
У конспекті лекцій систематизовані численні відомості, стандарти і підходи
до технічної реалізації концепції Інтернету речей (Internet of Things, IoT), а також
суміжних з ним інфокомунікаційних технологій (радіочастотної ідентифікації RFID,
бездротових сенсорних мереж WSN, міжмашинної комунікацій М2М). Розглянуто
протоколи і технології передачі даних.
Конспект лекцій призначений для бакалаврів, які навчаються за напрямом
Систесна інженерія (Інтернет речей).

1.2. Класифікація технологій передачі даних в IoT

Одним з головних питань організації Інтернету речей є реалізація взаємодії

між:
Інтернет-речами, користувачами і Інтернет-речами, віддаленим
сервером і Інтернет-речами.
IoT використовує велику кількість варіантів мереж зв'язку для передачі
даних, починаючи від мережі на тілі людини BAN (Body Area Network), яка працює
на відстані в кілька десятків сантиметрів, аж до всесвітньої мережі Інтернет.
Комунікації малої дальності використовують такі технології, як RFID, NFC, Bluetooth,
Wi-Fi і ін. Комунікації великого радіусу дії реалізуються на базі різних стільникових
мереж (2G / 3G / 4G), мереж бездротового широкосмугового доступу WiMAX, мереж
позиціонування GPS / ГЛОНАСС і ін.
Територією охоплення телекомунікаційні мережі, які використовуються в
Інтернеті речей, можна розділити на 4 основних типи (рис. 1.1):
 Рис. 1.1 - Ієрархія мережевих технологій, що використовуються в IoT

1. Персональна мережа PAN (Personal Area Network) - це мережа,

побудована «навколо» людини.
Дані мережі покликані об'єднувати всі персональні пристрої користувача
(телефони, смартфони, кишенькові персональні комп'ютери, ноутбуки, гарнітури і
ін.). Стосовно до IoT така мережа будується «навколо» пристрою ( «речі»).
2. Локальна мережа LAN (Local Area Network) - мережа, що покриває
зазвичай відносно невелику територію або невелику групу будівель (будинок, офіс,
фірму). До локальних мереж можна віднести і мережу контролерів CAN (Controller
Area Network) - промислову мережу, орієнтовану, перш за все, на об'єднання в єдину
мережу різних виконавчих пристроїв і датчиків в рамках окремого підприємства.
3. Міська мережа MAN (Metropolitan Area Network) - об'єднує окремих
користувачів і локальні мережі в межах міста, являє собою мережу за розмірами
більшу, ніж LAN, але меншу, ніж WAN.
4. Глобальна мережа WAN (Wide Area Network) - пов'язує користувачів і
мережі, розосереджені на відстані сотень і тисяч кілометрів.
Інтернет речей практично не висуває особливих вимог до технологій LAN,
MAN і WAN, крім того вони досить добре освітлені в технічній літературі. Тому в
цьому розділі розглянуто лише стандарти і протоколи мереж малого і середнього
радіусу дії, які широко використовуються в IoT.
Всі технології передачі даних в Інтернеті речей в залежності від
використовуваного середовища передачі можна розділити на два великі класи:
Провідні
і бездротові.
Провідні технології передачі даних в IoT можуть використовувати
металевий (мідний) кабель зв'язку, електропроводку (технологія PLC - Power Line
Communication) або волоконно-оптичний кабель. Однак, зважаючи на складнощі
фізичної реалізації ліній зв'язку провідні технології для комунікацій Інтернет-речей
застосовуються в меншій мірі, ніж бездротові.
Для бездротової передачі даних особливо важливу роль в побудові
Інтернету речей грають такі якості, як ефективність в умовах низьких швидкостей,
відмовостійкість, адаптивність, можливість самоорганізації.
Бездротові мережі для Інтернету речей підрозділяються на наступні
типи:
- Low Power Short Range Networks - енергоефективні мережі малого
радіусу дії;
- Бездротові мережі малого радіусу дії Low Power Wide Area Networks
(LPWAN) - енергоефективні мережі великого радіусу дії;
- Cellular Network - технології, засновані на використанні стандартів
стільникових мереж в ліцензованому діапазоні.
Short Range і LPWAN побудовані на використанні неліцензійного діапазону
частот - ISM Bands. У секторі Short Range виділяють стандарт IEEE 802.15.4, що
визначає фізичний шар і управління доступом для організації енергоефективних
персональних мереж, і є основою для таких протоколів, як ZigBee, WirelessHart,
MiWi, 6LoWPAN, а також Bluetooth low energy, NFC, WLAN (Wi -Fi). У секторі LPWAN
існують такі основні стандарти і технології - SigFox, Symphony Link, Nwave, Ingenu
(RPMA), Weightless, LoRa.
Окремо виділяються технології, що базують на мережах мобільного зв'язку,
що використовують ліцензовані частотні діапазони - стандарти eMTC, EC-GSM-IoT,
NB-IoT. eMTC і NB-IoT розгортається на обладнанні мереж LTE (також допускається
побудова виділених мереж NB-IoT в т.ч. в частотних каналах мереж GSM); EC-GSM-
IoT розгортається поверх мереж стандарту GSM. При цьому технологію NB-IoT
також прийнято відносити до енергоефективних мереж великого радіусу дії
(LPWAN).
Бездротові мережі малого радіусу дії, які використовуються в IoT, можна
розділити на три види:
1. Бездротові персональні мережі WPAN (Wireless Personal Area
Network).
Застосовуються для зв'язку різних пристроїв, включаючи комп'ютерну,
побутову та оргтехніку, засоби зв'язку і т.д. Фізичний і канальний рівні
регламентуються стандартом IEEE 802.15.4. Радіус дії WPAN становить від кількох
метрів до кількох десятків сантиметрів. Такі мережі використовуються як для
об'єднання окремих пристроїв між собою, так і для зв'язку їх з мережами більш
високого рівня, наприклад, глобальною мережею Інтернет. WPAN може бути
развѐрнута з використанням різних мережевих технологій, наприклад, Bluetooth,
ZigBee, 6LoWPAN і інших, розглянутих далі в цьому розділі.
2. Бездротові сенсорні мережі WSN (Wireless Sensor Network).
Распределені, самоорганізуються мережі безлічі датчиків (сенсорів)
виконавчих пристроїв, об'єднаних між собою за допомогою радіоканалу. Область
покриття подібних мереж може становити від декількох метрів до декількох
кілометрів за счѐт здатності ретрансляції повідомлень від одного елемента до
іншого.
3. Малі локальні мережі TAN (Tiny Area Network).
Обчислювальні мережі, що розгортаються в межах невеликого офісу або
окремого житла. Їх часто називають домашніми мережами, так як вони об'єднують
комп'ютери, побутову електроніку і прилади сигналізації, що належать одній родині.
Найбільш часто такі мережі будуються на базі технології Wi-Fi.

На рисунку 1.2. приведено порівняння технології LPWAN з іншими

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

Рис. 1.2

1.3. Стандартизація IoT

Питаннями стандартизації та практичного впровадження окремих складових

Інтернету речей (М2М, RFID, всепроникні сенсорні мережі та ін.) Займаються багато
міжнародних організацій, неурядові асоціації, альянси виробників і операторів,
партнерські проекти. В цілому для Інтернету речей, як нового напрямку розвитку
інфокомунікацій, в даний час визначені найзагальніші концептуальні та архітектурні
рішення. Найближчим часом основною проблемою буде гармонізації різних
стандартів з метою формування єдиної і несуперечливої нормативної бази для
практичної реалізації Інтернету речей.
В рамках діяльності сектора стандартизації телекомунікацій Міжнародного
союзу електрозв'язку (МСЕ-Т) є три глобальні ініціативи GSI (Global Standards
Initiative). Під глобальної ініціативою розуміється комплекс робіт, виконуваних
паралельно різними дослідницькими комісіями МСЕ відповідно до скоординованим
планом роботи. Одна з таких ініціатив присвячена стандартизації Інтернету речей -
IoT-GSI (Global Standards Initiative on Internet of Things). Дві інші глобальні ініціативи
- по стандартизації мереж наступних поколінь NGN-GSI і систем телебачення на
основі протоколу Інтернет IPTV-GSI - також базуються на використанні IP-
технологій, як і IoT-GSI.
IoT-GSI будує свою роботу на основі зусиль МСЕ-Т в таких областях, як
мережеві аспекти ідентифікаційних систем (Network Identificator, NID), всепроникні
сенсорні мережі (Ubiquitous Sensor Networks, USN), межмашинного зв'язок (M2М),
WEB речей (WoT) і т.п. В рамках серії МСЕ-Т Y.2хxx, присвяченій мереж наступного
покоління NGN, вже затверджені перші рекомендації, присвячені спеціально
Інтернету речей: Y.2060 «Огляд Інтернету речей», Y.2063 «Основа WEB речей» і
Y.2069 «Терміни та визначення Інтернету речей » і ін.
В Рекомендації Y.2060 приведена еталонна модель IoT, яка дуже схожа на
модель NGN і також включає чотири базових горизонтальних рівня (рис. 1.3):
- рівень додатків IoT;
- рівень підтримки додатків і послуг;
- мережевий рівень;
- рівень пристроїв.

Рис. 1.3 - Еталонна модель IоT згідно МСЕ-Т Y.2060

 Рівень додатків IoT в Рекомендації Y.2060 детально не розглядається.
Але на сьогоднішній день можемо зазначити, що на цьому рівні існують різні
типи додатків для відповідних промислових секторів і сфер діяльності (енергетика,
транспорт, торгівля, медицина, освіта та ін.). Додатки можуть бути
«вертикальними», коли вони є специфічними для конкретної галузі промисловості,
а також «горизонтальними», (наприклад, управління автопарком, відстеження
активів і ін.), які можуть використовуватись в різних секторах економіки.
Рівень підтримки додатків і послуг (сервісний) включає загальні
можливості для різних об'єктів IoT з обробки та зберігання даних, а також
можливості, необхідні для деяких додатків IoT або груп таких додатків.
Рівень містить набір інформаційних послуг, покликаних автоматизувати
технологічні і бізнес операції в IoT: підтримки операційної і бізнес діяльності (OSS /
BSS, Operation Support System / Business Support System), різної аналітичної
обробки інформації (статистичної, інтелектуального аналізу даних і текстів,
прогностична аналітика і ін.), зберігання даних, забезпечення інформаційної
безпеки, управління бізнес-правилами (BRM, Business Rule Management),
управління бізнес-процесами (BPM, Business Process Management) і ін.
Мережевий рівень (рівень шлюзів і мереж) включає мережеві можливості
(функція управління ресурсами мережі доступу та транспортної мережі, управління
мобільністю, функції авторизації, аутентифікації і розрахунків) і транспортні
можливості (забезпечення зв'язності мережі для передачі інформації додатків і
послуг IoT). Даний рівень складається з конвергентної мережевої інфраструктури,
яка створюється шляхом інтеграції різнорідних мереж в єдину мережеву
платформу. Конвергентний абстрактний мережевий рівень в IoT дозволяє через
відповідні шлюзи декільком користувачам використовувати ресурси в одній мережі
незалежно і спільно без шкоди для конфіденційності, безпеки і продуктивності.
Конвергентна інфраструктура означає сумування серверних
платформ, безлічі мереж різних технологій і протоколів доступу, систем зберігання
даних , мережевого устаткування, технологій віртуалізації і ряду інших ресурсів в
одне інтегроване рішення, кероване як єдине ціле (для забезпечення спільної
роботи), а не за допомогою окремих засобів адміністрування.
Рівень пристроїв складається з «розумних» (smart) пристоїв, інтегрованих
з сенсорами (датчиками). Сенсори реалізують з'єднання фізичного і віртуального
(цифрового) світів, забезпечуючи збір та обробку інформації в реальному масштабі
часу. Існують різні типи сенсорів для відповідних цілей, наприклад, для вимірювання
температури, тиску, швидкості руху, місця розташування та ін. Сенсори можуть мати
невелику пам'ять, даючи можливість записувати кілька результатів вимірювань.
Сенсор може вимірювати фізичні параметри контрольованого об'єкта / явища і
перетворити їх в сигнал, який може бути прийнятий відповідним пристроєм. Сенсори
класифікуються відповідно до їх призначення, наприклад, сенсори навколишнього
середовища, сенсори для тіла, сенсори для побутової техніки, сенсори для
транспортних засобів і т.д.
Більшість сенсорів вимагає з'єднання з агрегатором сенсорів (шлюзом), які
можуть бути реалізовані з використанням локальної обчислювальної мережі (LAN,
Local Area Network), таких як Ethernet і Wi-Fi або персональної мережі (PAN, Personal
Area Network), таких як ZigBee , Bluetooth і ультрашірокополосной бездротового
зв'язку на малих відстанях (UWB, Ultra-Wide Band). Для сенсорів, які не вимагають
підключення до агрегатору, їх зв'язок з серверами / додатками може надаватися з
використанням глобальних бездротових мереж WAN, таких як GSM, GPRS і LTE.
Сенсори, які характеризуються низьким енергоспоживанням і низькою швидкістю
передачі даних, утворюють широко відомі бездротові сенсорні мережі (WSN,
Wireless Sensor Network). WSN набирають все більшої популярності, оскільки вони
можуть містити набагато більше сенсорів з підтримкою роботи від батарей і
охоплюють великі площі.
Існує також два вертикальних рівня - рівень управління і рівень безпеки, що
охоплюють всі чотири горизонтальних рівня. Можливості вертикального рівня
експлуатаційного управління передбачають управління наслідками відмов,
можливостями мережі, конфігурацією, безпекою та даними для білінгу. Основними
об'єктами управління є пристрої, локальні мережі та їх топологія, трафік і
перевантаження на мережах.
Можливості вертикального рівня безпеки залежать від горизонтального
рівня. Для рівня підтримки програм та послуг: захист, тести цілісності даних. Для
мережевого рівня - можливості авторизації, автентифікації, захисту інформації
протоколів сигналізації. На рівні пристроїв - можливості авторизації, автентифікації,
контроль доступу і конфіденційність даних.
Основною метою проекту Європейського інтеграційного проекту IoT-A
(Internet of Things - Architecture), учасниками якого є різні компанії, є розробка
еталонної архітектурної моделі Інтернету речей з описом основних складових
компонентів, яка б дозволила інтегрувати різнорідні технології IoT в єдину
взаємопов'язану архітектуру.
Функціональна модель IoT-A (рис. 1.4) дещо відрізняється від моделі МСЕ
рис. 1.5), хоча вона теж є ієрархічною, але складається вже з семи горизонтальних
рівнів, що доповнюються двома вертикальними (управління і безпеку), які беруть
участь у всіх процесах.

Рис. 1.4 - Функціональна модель архітектури IoT-A

Якщо звернутися до технічних особливостей моделі на рис. 1.3, то можна

сказати, що модель передачі даних в Інтернеті речей IoT-A буде відрізнятися від
існуючої моделі передачі даних через Інтернет. У моделі архітектури IoT-A
фігурують два важливих поняття. Мережа з обмеженнями характеризується
відносно низькими швидкостями передачі - менше 1 Мбіт (наприклад, стандарт IEEE
802.15.4) і досить високими затримками. Мережа без обмежень відповідно
характеризується високими швидкостями передачі даних (десятки Мбіт/с і більше) і
схожа на існуючу мережу Інтернет. Різниця даних моделей мереж показано на рис.
1.5.

Рис. 1.5 – Порівняння моделей передачі даних в Інтернеті і в IoT

У моделі архітектури IoT фігурують два важливих поняття.

Мережа з обмеженнями характеризується
 відносно низькими швидкостями передачі
 досить високими затримками
Мережа без обмежень характеризується
 високими швидкостями передачі даних.

Шлюз для Інтернету речей (IoT Gateway) - сполучна ланка між рівнями контролю
і управління Інтернету речей (IoT), а саме конвертує протоколи одного типу
фізичного середовища в протоколи іншого фізичного середовища (мережі).
Наприклад:
Технології для пристроїв Шлюз ІТ
ІoT: Технології для мереж
CAN, Ethernet, RS-232, RS- доступу/транспортних
485, ZigBee, Bluetooth, WiFi, мереж:
LoRa і ін. 2G/3G/4G, GPRS, WiFi і ін.

IoT-шлюз підтримує додаткові функції:

 збір, обробка та оцінка великих обсягів даних
 завантаження даних в хмарні платформи, такі як Microsoft® Azure, Amazon
 Web Services для подальшого аналізу.

Для взаємодії величезної кількості різноманітних пристроїв в IoT потрібні

стандартизовані інтерфейси, формати даних і комунікаційні протоколи. У табл. 1.1
наведено перелік деяких стандартів і протоколів IoT із зазначенням робочої
частоти, швидкості передачі даних, підтримки рівнів OSI (фізичного PHY, доступу
до середовища MAC, мережевого NWK, транспортного TRP), а також реалізації
підрівні підтримки додатків APS (Application Support Sublayer), підтримки списків
управління доступом ACL (Access Control List) і 128-бітного стандарту шифрування
AES (Advanced Encryption Standart).
Таблиця 5.1 – Стандарти і протоколи IoT
Рівні протокола

Шифрування
Частота, Швидкість,
Кбіт/с
Стандарт P M N T A A
МГц H A W R P C
Y C K P S L

IEEE 868/915/2 20/40/

802.15.4 400 250 + + - - - + +

ZigBee 2400 250 - - + + + + +

6LoWPAN - 50-200 - - + - - + +

WirelessH ART
2400 250 + + + + + + +

ISA100.11 a
2400 250 + + + + + + +

865/915/8
Z-Wave 69 9,6/40 + + + - + - -

Bluetooth LE
2400 1000 + + + + + + +

DECT ULE 1880-1900 1000 + + + - - + +

1.4. Термінологія Інтернету речей

Приведемо список визначень ключових термінів з Рекомендації Y.2060:
Мережа зв'язку (Communication Network): інфраструктурна мережа, що
з'єднує пристрої та додатки, така як мережа на основі стека протоколів IP або
Інтернет.
Річ (Thing): предмет фізичного світу (фізичні речі) або інформаційного світу
(віртуальні речі), яка може бути ідентифікована та інтегрована в мережі зв'язку.
 Пристрій (Device): елемент обладнання, який володіє обов'язковими
можливостями зв'язку та додатковими можливостями вимірювання,
спрацьовування, а також введення, зберігання і обробки даних.
Пристрій переносу даних (Data-carrying Device): пристрій переносу даних
підключається до фізичної речі і непрямим чином з'єднує цю фізичну річ з мережами
зв'язку. Прикладами можуть служити активні мітки RFID.
Пристрій збору даних (Data-capturing Device): під пристроєм збору даних
розуміється пристрій, що зчитуючий/записуючий пристрій, що має можливість
взаємодії з фізичними речами. Взаємодія може здійснюватися непрямим чином за
допомогою пристроїв перенесення даних або безпосередньо за допомогою носіїв
даних, підключених до фізичних речей.
Носій даних (Data Carrier): безбатарейний об'єкт перенесення даних,
підключений до фізичної речі і має можливість надавати інформацію придатному
для цього пристрою збору даних. Ця категорія включає штрих-коди і QR-коди,
наклеєні на фізичні речі.
Сенсорний пристрій (Sensing Device): пристрій, який може виявляти або
вимірювати інформацію, що відноситься до навколишнього середовища, і
перетворювати її в цифрові електричні сигнали.
Виконавчий пристрій (Actuating Device): пристрій, який може перетворювати
цифрові електричні сигнали, що надходять від інформаційних мереж, в дію.
Пристрій загального призначення (General Device): пристрій загального
призначення володіє вбудованими можливостями обробки і зв'язку і може
обмінюватися даними з мережами зв'язку з використанням дротових або
бездротових технологій. Пристрої загального призначення включають обладнання
та прилади, які стосуються різних галузей застосування IoT, наприклад, верстати,
побутові електроприлади і смартфони.
Шлюз (Gateway): елемент IoT, що з'єднує пристрої з мережами зв'язку. Він
виконує необхідну трансляцію між протоколами, що використовуються в мережах
зв'язку і в пристроях.

1.5. Топологія мережі Інтернету речей

Однією з найбільш важливих складової Інтернету речей є власне Інтернет.

Однак, не варто буквально сприймати це. Далеко не всі пристрої в поточний момент
і в найближчій перспективі отримають прямий доступ в Інтернет. Як правило, всі
пристрої підключені в мережу, але ці мережі, як правило, відрізняються від
традиційного розуміння Інтернету більшістю.
Це явище обумовлено специфікою роботи пристроїв в Інтернеті речей.
Більшості пристроїв (особливо Інтернету речей) не вимагає високошвидкісний
постійний доступ в мережу. У той же час такі характеристики мереж, як надійність
з'єднання і енергоспоживання виходять як на першу роль, тому що, як було озвучено
раніше, є основними факторами для побудови Інтернету речей. Як наслідок, мережі
Інтернету речей в більшості випадків значно відрізняються від традиційного
Інтернету в тому вигляді в якому до нього звикли бачити.
Варто зазначити, що Інтернет речей може і в загальному випадку повинен
використовувати частину традиційного Інтернету для передачі даних і комунікації з
традиційними пристроями. Для цього існують шлюзи, які подібно до традиційних
шлюзів і маршрутизаторів перетворюють і передають дані між різними за
характером і типом мережами.
Більшість пристроїв Інтернету речей не вимагає високошвидкісний
постійний доступ в мережу, але ставляться інші вимоги мереж для IoT , як:
 надійність з'єднання
 енергоспоживання
 ефективність в умовах низьких швидкостей,
 відмовостійкість,
 адаптивність,
 можливість самоорганізації.

Розглянемо якими бувають мережі. Розгляд почнемо з топології. Їх можна

вважати рівнем моделі OSI/ISO, ТСР/ІР, що визначає фізичне з'єднання пристроїв
між собою. Однак, в більшості випадків, топологія має на увазі і другий рівень
моделі, тому що забезпечує адресацію всередині самої мережі.
Топологія шина (bus) - всі пристрої підключені до загального каналу
передачі даних і обмінюються даними, як правило, послідовно з поділом за часом,
тому що одні й ті ж дані отримують одночасно вузли підключені до шини. Як
наслідок, щоб не виникало колізій одночасно передавати дані в мережу може тільки
один вузол. В результаті досягається простота з'єднання (підключення) пристроїв
до мережі і передачі даних, однак швидкість виходить досить низька. Це тип мереж
все ще широко поширений для датчиків і малої промислової автоматизації. По
ньому працює RS-485.

Бездротові технології з низькою потужністю підтримують до п'яти

основних топологій мережі:
Трансляція (broadcast) - повідомлення передається від передавача до
будь-якого приймача в межах досяжності. Канал є однонаправленим без
підтвердження, що повідомлення було отримано.

Рівний до рівного (peer-to-peer, p2p) — архітектура системи, в основі якої

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

Зірка (Star). Центральний трансивер здійснює зв'язок між двонаправленими

каналами з кількома периферійними приймачами. Периферійні приймачі не можуть
безпосередньо спілкуватися один з одним.
Зірка - безліч з'єднань точка-точка об'єднаних з одним вузлом (центральний
трансивер), передача даних між двома кінцевими вузлами відбувається через
нього. На даному принципі побудовані більшість мереж Ethernet, традиційно
застосовуваних для підключення персональних комп'ютерів. Однак, даний
стандарт отримав значно більшого поширення останнім часом і його
використовують тепер для дуже великої кількості пристроїв. Wi-Fi в загальному
випадку також працює по даній топології. Пропускна здатність визначається
швидкістю кожного з'єднання вузла і центрального трансивера, а також можливістю
трансивера обробляти кілька з'єднань одночасно (практично всі сучасні пристрої це
можуть). Дані в мережі отримують тільки ті пристрої, які знаходяться на шляху
передачі даних (вихідний вузол, трансивер і кінцевий вузол).

Сканування. Центральний скануючий пристрій залишається в режимі

прийому, очікуючи на отримання сигналу від будь-якого передавального пристрою
в межах досяжності. Зв'язок знаходиться в одному напрямку.
 Комірчаcті мережі (mesh network) - Комірчаті мережі (mesh network) -
мережі даної топології як правило не мають певної топології, утворюються на основі
безлічі з'єднань «точка-точка» вузлів тому, що в загальному випадку всі пристрої
можуть взаємодіяти між собою. Але, на відміну від загальної шини в даній топології
мережі немає (або може не бути) прямого контакту між будь-якими двома
учасниками даної мережі. Як правило даний тип мереж характерний для
безпровідних приймачів/передавачів, тому що практично неможливо забезпечити
фізичний (електричний) контакт між двома випадковими двома вузлами, які
знаходяться поряд в провідних мережах, тому що сигнал передається по кабелях і
структура мережі жорстко фіксована. При цьому в разі використання безпровідних
приймачів/передавачів останнє обмеження відсутнє і загальне з'єднання
досягається за рахунок загального середовища (радіоефіру). Варто відзначити такі
важливі властивості комірчастих мереж, як самоорганізованість (здатність в
автоматичному режимі визначити топологію мережі і шлях передачі даних між
вузлами). Ці якості є основними і тому неможливо розглядати мережі цієї топології
тільки на першому рівні моделі OSI/ISO.
Як можна було здогадатися, найбільш перспективними для Інтернету речей
є якраз комірчаті мережі, по крайній мері на останній її ділянці, так званої «останньої
милі».
Ключова властивість – самоорганізація:
1. здатність в автоматичному режимі визначити топологію мережі і
шлях передачі даних між вузлами
2. будь-який вузол може виконувати функції транзитної передачі
пакетів (маршрутизації) для інших учасників мережі.

Гібридні мережі (hybrid networks) - можуть включати в себе мережі різних

топологій. У загальному випадку можна сказати, що Інтернет є гібридною мережею,
тому що включає в себе практично всі їх описаних вище топологій в тих чи інших
сегментах.
У підсумку можна зробити наступні висновки:
• найбільш поширеними мережами для Інтернету речей є (за кількістю і
функціональності):
- шина (для пристроїв RS-485),
- зірка (Ethernet, Wi-Fi, BT),
- комірчасті (ZigBee, 6LoWPAN, LoRa-mesh та ін),
 Комірчаті мережі для бездротових пристроїв в мережі в даний момент
знаходяться в активному розвитку і володіють дуже великими перспективами для
IoT,
 Топологія мереж самого Інтернету не має жорсткої структури і
відноситься до гібридної мережі.
 1

Тема 2. Протоколи передачі даних Інтернету речей та підключення

1.1. Історія створення і розвитку протололів Інтернету речей.
1.2. Протоколи Інтернету речей: як пристрої Інтернету речей обмінюються
даними з мережею.
1.3. Протоколи прикладного рівня.
2.3.1. Протоколи HTTP/HTTPS, CoAP.
2.3.2. Протокол MQTT.

2.1. Історія створення і розвитку протололів Інтернету речей

У зв'язку з швидким розвитком Інтернету речей та винятковими

особливостями даної мережі (наприклад, пристрої з низьким енергоспоживан ням,
низькі швидкості передачі і т.д.) виникла необхідність у створенні протоколів, які
будуть задовольняти цим вимогам.
Так заміною в мережі IoT всім відомого протоколу HTTP є протокол CoAP,
призначений для використання пристроями з низькою швидкістю, високими
втратами, багатоадресною розсилкою в мережі. У 1999 році був представлений
протокол MQTT (Message Queuing Telemetry Transport), але широко поширеним
став лише після 2010 року. MQTT спеціалізується на низькошвидкісних
середовищах з високою затримкою, тому добре підходить для обміну даними між
машинами (M2M).
У 2002 році була сформована робоча група XMPP, для розробки протоколу
на основі Jabber для миттєвого обміну повідомленнями. Робоча група сформувала
чотири специфікації, які були оформлені в якості стандартів в 2004 році.
Крім того, часто розробники використовують власні пропрієтарні протоколи,
однак використання стандартних протоколів на IoT-платформах значно
прискорюють впровадження і розробку нових систем і додатків Інтернету речей.
Підхід до класифікації протоколів інтернету речей передбачає об'єднання
протоколів за місцем застосування в клієнт-серверній архітектурі мережі,
розробники пропонують наступну модель взаємодії пристроїв IoT в мережі
Інтернет:
 D2D (Device to Device) - протоколи взаємодії кінцевих пристроїв між
собою (найпоширеніший протокол DDS);
 D2S (Device to Server) - для передачі даних, зібраних кінцевими
пристроями на сервери для подальшого аналізу обробки (найпоширеніші протоколи
CoAP, MQTT, XMPP, STOMP);
 S2S (Server to Server) - протоколи взаємодії серверів один з одним
(найпоширеніший протокол AMQP). Сервер може включати в себе декілька
обчислювальних машин або об'єктів, які також потребують спілкування між собою
Для виконання моделей D2D, D2S, S2S необхідно використання різних
протоколів.
 AMQP (Advanced Message Queuing Protocol) - відкритий стандарт протоколу
прикладного рівня для проміжного програмного забезпечення, орієнтованого на
обробку повідомлень. Семантика обміну повідомленнями налаштовується під
 2

потреби конкретного проекту. «Брокер повідомлень», який здійснює

маршрутизацію, зазвичай гарантує доставку, розподіл потоків даних, черговість,
підписку на потрібні типи повідомлень. Архітектуру протоколу розробив John
O'Hara з банку JP Morgan Chase & Co. «Повідомлення» (message)
відправляються в «точку обміну». Точка обміну розподіляє повідомлення в одну
або кілька «черг». При цьому в точці обміну повідомлення не зберігаються. В
якості транспорту - TCP/UPD.
 XMPP (Extensible Messaging and Presence Protocol) – відкритий протокол для
миттєвого обміну повідомленнями та інформацією про присутність між
користувачами в мережі Інтернет, в режимі близькому до режиму реального часу.
Стосовно до Інтернету речей XMPP забезпечує простий спосіб адресації
пристроїв. Для ідентифікації користувачів використовуються ідентифікатори
Jabber ID, за форматом схожі на адреси електронної пошти (наприклад,
username@jabber.uа). У протоколі XMPP застосовується текстовий формат XML
(Мова XML призначена для зберігання і передачі даних, а HTML же призначений
для відображення даних). В якості транспорту використовується протокол TCP.
XMPP підтримує різні комунікаційні моделі (запит-відповідь, публікація-підписка і
інші).
 STOMP – (Simple Text Oriented Message Protocol) - простий протокол обміну
повідомленнями, що передбачає широку взаємодію з багатьма мовами,
платформами і брокерами. Даний протокол підходить під шаблон "видавець-
підписник". Протокол в цілому схожий на HTTP, використовує транспорт TCP.

2.2. Протоколи Інтернету речей: як пристрої Інтернету речей

обмінюються даними з мережею
Пристрої Інтернету речей обмінюються даними за допомогою протоколів
Інтернету речей. Протокол IP - це набір правил, що визначають спосіб відправки
даних в Інтернет. Протоколи Інтернету речей гарантують, що інформація з одного
пристрою або датчика буде зчитуватися і правильно інтерпретуватися іншим. Так
як існує безліч пристроїв Інтернету речей, важливо використовувати потрібний
протокол в потрібному контексті.
Після появи і розвитку Інтернету речей стало зрозуміло, що не всі існуючі
протоколи здатні забезпечувати виконання завдань, покладених на технології
розподілених обчислень, вбудовані датчики, пристрої, сучасні бездротові
технології.
Наприклад, пристрої з низьким енергоспоживанням, низькими
швидкостями передачі.
Тип використовуваного протоколу Інтернету речей залежить від рівня
архітектури системи, на якому повинні передаватися дані. Модель ТСР/IP надає
карту різних рівнів, на яких виконується відправка і отримання даних.
Отже, кожен протокол в архітектурі системи Інтернету речей забезпечує
взаємодію між пристроями, між пристроєм і шлюзом, між шлюзом і центром
 3

обробки даних або між шлюзом і хмарою, а також обмін даними між центрами
обробки даних.
Сучасні IoT-рішення будуються на базі протоколів передачі даних
(наприклад, MQTT, AMQP, HTTP, CoAP і інші) і забезпечують взаємодію кінцевих
пристроїв з хмарними сервісами (наприклад, Azure IoT Suite, Amazon Web Services
IoT). https://azure.microsoft.com/ru-ru/overview/internet-of-things-iot/iot-technology-
protocols/
На сьогодні, протоколи розроблені спеціально для задоволення вимог IoT у
більшості літературних джерел розглядаються з прив’язкою до рівнів моделі
TCP/IP: прикладного, транспортного, мережевого і канального, оскільки значна
частина протоколів моделі TCP/IP підтримує також роботу пристроїв Інтернету
речей.

ТСР/ІР

Прикладний рівень - ПРОТОКОЛИ: DHCP, DNS, FTP, HTTP,

служить інтерфейсом для HTTPS, IMAP, POP3, SIP, SMTP, SSH, Telnet,
обміну даними між Modbus
користувачем і пристроєм. ПРОТОКОЛИ IoT: BACnet, MQTT, CoAP,
Саме на цьому рівні DDS, XMPP, STOMP, AMQP, CAP
працюють всі прикладні
програми, які
використовують доступ до
мережі.
ПРОТОКОЛИ: TCP, UDP

Транспортний рівень
- забезпечує і захищає обмін
даними між рівнями.

ПРОТОКОЛИ: IPv4, IPv6, ICMP, ICMPv6

Мережевий рівень -
ПРОТОКОЛ IoT: 6LoWPAN - версія IPv6 з
допомагає окремим
меншою потужністю, яка скорочує час передачі.
пристроям взаємодіяти з
маршрутизатором.
 4

Канальний рівень -
на цьому рівні дані
передаються в межах
СТАНДАРТ: ІEEE 802.3, ІEEE 802.11
архітектури системи. При
СТАНДАРТ: з низьким енергоспоживанням IEEE
цьому визначаються і
802.15.4, IEEE 802.15.5
виправляються помилки,
виявлені на фізичному
рівні.

Стовп протоколу TCP / IP знаходиться в центрі Інтернету. Він може бути

представлений за допомогою семи рівневої контрольної моделі OSI, як показано
нижче. Три основних рівні згруповані разом, що спрощує модель.

Довідкова модель стека TCP / IP

2.3. ПРОТОКОЛИ ПРИКЛАДНОГО РІВНЯ

Протокол динамічної конфігурації вузла DHCP

DHCP (Dynamic Host Configuration Protocol). Протокол динамічної
конфігурації вузла, що дозволяє пристрою автоматично отримувати IP-адресу та
інші параметри, необхідні для роботи в мережі TCP/IP.
Протокол DHCP є клієнт-серверним, в роботі беруть участь клієнт DHCP і
сервер DHCP. Передача даних здійснюється за допомогою протоколу UDP, при
цьому сервер приймає повідомлення від клієнтів на порт 67 і відправляє
 5

повідомлення клієнтам на порт 68.

Мережевий адміністратор може задати діапазон адрес, які будуть
розподілені між комп'ютерами. Це дозволяє уникнути ручного налаштування
комп'ютерів (пристроїв) мережі й зменшує кількість помилок. Протокол DHCP
використовується в більшості великих мереж TCP/IP.
Адміністратор може задати діапазон адрес, що розподіляють сервером
серед комп'ютерів. Це дозволяє уникнути ручного налаштування комп'ютерів
мережі й зменшує кількість помилок. Протокол DHCP використовується в більшості
мереж TCP/IP.
DHCP може бути налаштований на маршрутизаторах або на базі будь-якого
сервера.
В IoT служить для моніторингу працездатності DHCP-сервера.

Розподіл IP-адрес
Протокол DHCP надає три способи розподілу IP-адрес :
Ручний розподіл. При цьому способі мережевий адміністратор зіставляє
апаратну адресу (для Ethernet-мереж це MAC-адресу ) кожного клієнтського
комп'ютера з певним IP-адресом. Фактично даний спосіб розподілу адрес
відрізняється від ручної настройки кожного комп'ютера лише тим, що відомості про
адреси зберігаються централізовано (на сервері DHCP), і тому їх простіше
змінювати при необхідності.
Автоматичний розподіл. При даному способі кожному комп'ютеру на
постійне використання виділяється довільний вільний IP-адрес адміністратором з
певного діапазону.
Динамічний розподіл. Цей спосіб аналогічний автоматичному розподілу за
винятком того, що адреса видається комп'ютеру не на постійне користування, а на
певний термін. Це називається орендою адреси . Після закінчення терміну оренди
IP-адреса знову вважається вільною, і клієнт зобов'язаний запросити новий (він,
втім, може виявитися тим же самим). Крім того, клієнт сам може відмовитися від
отриманої адреси.
Деякі реалізації служби DHCP здатні автоматично оновлювати записи DNS
, відповідні клієнтським комп'ютерам, при виділенні їм нових адрес. Це робиться за
допомогою протоколу поновлення DNS, описаного в RFC 2136 .
Опції DHCP
Крім IP-адреси, DHCP також може повідомляти клієнтові додаткові
параметри, необхідні для нормальної роботи в мережі. Ці параметри називаються
опціями DHCP. Список стандартних опцій можна знайти в RFC 2132 .
Деякими з найбільш часто використовуваних опцій є:
- IP-адреса маршрутизатора за замовчуванням (основний шлюз);
- маска підмережі;
- адреси серверів DNS;
- ім'я домену DNS.
Деякі постачальники програмного забезпечення можуть визначати власні,
додаткові опції DHCP.
Як вже вище було зазначено, протокол DHCP є клієнт-серверним , тобто в
його роботі беруть участь клієнт DHCP і сервер DHCP. Транспорт здійснюється за
 6

допомогою протоколу UDP. За замовчуванням запити від клієнта робляться на 67

порт до сервера, сервер в свою чергу відповідає на порт 68 до клієнта, видаючи
адресу IP і іншу необхідну інформацію, таку, як мережеву маску, маршрутизатор і
сервери DNS.
Приклад процесу отримання адреси
Розглянемо приклад процесу отримання IP-адреси клієнтом від сервера
DHCP, рис. 2.1. Припустимо, клієнт ще не має власного IP-адресу, але йому
відомий його попередній адрес - 192.168.1.100. Процес складається з чотирьох
етапів. Ці етапи часто скорочуються як DORA (Discovery, Offer, Request, і
Acknowledgement)

Рис.2.1. Процес отримання IP-адреси клієнтом від сервера DHCP

Виявлення DHCP
На початку клієнт виконує циркулярний запит по всій фізичної мережі з
метою виявити доступні DHCP-сервери. Він відправляє повідомлення типу
DHCPDISCOVER , при цьому в якості IP-адреси джерела вказується 0.0.0.0 (якщо
комп'ютер ще не має власної IP-адреси), а в якості адреси призначення -
широкомовна адреса 255.255.255.255.
Клієнт заповнює кілька полів повідомлення початковими значеннями:
В поле xid поміщається унікальний ідентифікатор транзакції , який дозволяє
відрізняти даний процес отримання IP-адреси від інших, що протікають в той же
час.
В поле chaddr поміщається апаратна адреса ( MAC-адреса ) клієнта.
В поле опцій вказується останній відомий клієнту IP-адрес. В даному
прикладі це 192.168.1.100. Це необов'язково і може бути проігноровано сервером.
Повідомлення DHCPDISCOVER може бути поширене за межі локальної
фізичної мережі за допомогою спеціально налаштованих агентів ретрансляції
DHCP , що перенаправляє отримані від клієнтів повідомлення до DHCP серверів в
інших підмережах.
Не завжди процес отримання IP-адреси починається з DHCPDISCOVER . У
разі, якщо клієнт раніше вже отримував IP-адрес і термін його оренди ще не
пройшов - клієнт може пропустити стадію DHCPDISCOVER, почавши з запиту
DHCPREQUEST відправляється з ідентифікатором сервера, який видав адресу в
 7

минулий раз. У разі ж відсутності відповіді від DHCP-сервера, яка видала настройки
в минулий раз, клієнт відправляє DHCPDISCOVER . Тим самим клієнт починає
процес отримання з початку, звертаючись уже до всіх DHCP-серверів у тій частині
мережі.
Пропозиція DHCP
Отримавши повідомлення від клієнта, сервер визначає необхідну
конфігурацію клієнта відповідно до зазначених мережевим адміністратором
настройками. В даному випадку DHCP-сервер згоден з запитаним клієнтом
адресою 192.168.1.100. Сервер відправляє йому відповідь ( DHCPOFFER ), в якому
пропонує конфігурацію. Пропонований клієнту IP-адреса вказується в поле yiaddr .
Інші параметри (такі, як адреси маршрутизаторів і DNS -серверів) вказуються у
вигляді опцій у відповідному полі.
Це повідомлення DHCP-сервер відправляє хосту, який послав
DHCPDISCOVER, на його MAC, при певних обставинах повідомлення може
поширюватися як широкомовлення. Клієнт може отримати кілька різних пропозицій
DHCP від різних серверів; з них він повинен вибрати те, яке його «влаштовує».
Запит DHCP
Вибравши одну з конфігурацій, запропонованих DHCP-серверами, клієнт
відправляє запит DHCP (DHCPREQUEST). Він розсилається широкомовно; при
цьому до опцій, зазначеним клієнтом в повідомленні DHCPDISCOVER, додається
спеціальна опція - ідентифікатор сервера - вказує адресу DHCP-сервера, обраного
клієнтом (в даному випадку - 192.168.1.1).
Підтвердження DHCP
Нарешті, сервер підтверджує запит і направляє це підтвердження (
DHCPACK ) клієнту. Після цього клієнт повинен налаштувати свій мережевий
інтерфейс, використовуючи надані опції.

Доменна система імен DNS

Доменна система імен ( Domain Name System, DNS) — ієрархічна
розподілена система перетворення імені хоста (комп'ютера або іншого мережевого
пристрою) в IP-адресу.
DNS - це розподілена база даних, реалізована в ієрархії серверів імен. Це
протокол прикладного рівня для обміну повідомленнями між клієнтами та
серверами.
Кожен комп'ютер в Інтернеті має свою власну унікальну адресу — число,
яке складається з чотирьох (у протоколі IPv4) або шістнадцяти (у протоколі IPv6)
байтів. Оскільки запам'ятати десятки чи навіть сотні номерів — важка процедура,
то всі (чи майже всі) машини мають імена, запам'ятати які (особливо якщо знати
правила утворення імен) значно легше.
DNS (Domain Name System). Протокол для отримання IP-адреси по імені
пристрою. Cистема DNS дозволяє перетворювати імена комп’ютерів в IP-
адреси.
DNS важлива для роботи Інтернету, так як для з'єднання з вузлом необхідна
інформація про його IP-адресу, а для людей простіше запам'ятовувати буквені
(зазвичай осмислені) адреси, ніж послідовність цифр IP-адреси. Наприклад,
https://lpnu.ua/ - 195.22.112.15.
 8

Протокол DNS використовує для роботи TCP-або UDP-порт 53.

В IoT використовується для моніторингу працездатності DNS-сервера.
Ієрархія і делегування доменних імен
Домен є іменована гілка в дереві імен, що включає в себе сам вузол (напр.,
Домен першого рівня ".com"), а також підлеглі йому вузли (напр., Домен другого
рівня "example.com", домен третього рівня "mail .example.com "і т.д.). Для
позначення ієрархічної приналежності доменних імен прийнято використовувати
поняття "рівень" - показник становища вузла в дереві доменів рис. 6.3. Чим нижче
значення рівня, тим вище ієрархічне положення домену
"." - домен нульового рівня
".соm" - домен першого (верхнього) рівня
"google.com" - домен другого рівня
" plus.google.com " - домен третього рівня
Цей список можна продовжувати
Приклад структури доменного імені рис.2.2.

Рис. 2.2. Приклад структури доменного імені

Зверніть увагу на домен нульового рівня "." (dot - точка) , також званий
кореневим. На практиці точку зазвичай не вказують ("example.com" замість
"example.com."), Тобто вказівка кореневого домена не є обов'язковим умовам
дозволу IP-адреси. Більшість клієнтських програм (інтернет-браузерів і т.д.)
додають домен нульового рівня автоматично і не відображають його користувачеві.
Доменне ім'я, що не включає позначення домену нульового рівня називається
відносним, що включає саму точку на кінці - повністю певним (FQDN - Fully Qualified
Domain Name) .
• Дозвіл адресів DNS: крок 1
 9

Дозвіл адресів DNS: крок 2

Схеми запитів DNS-імен:

• Рекурсивна процедура
• Нерекурсивна процедура
Рекурсивна процедура:
1. DNS-клієнт запитує локальний DNS-сервер, який обслуговує піддомен, якому
належить клієнт;
2. Далі, якщо локальний DNS-сервер відповідь знає, то повертає її клієнту, в
протилежному випадку виконує ітеративні запити до кореневого сервера до
тих пір, поки не отримає відповідь.
Після отримання відповіді сервер передає її клієнту. Таким чином, при
рекурсивній процедурі клієнт фактично передоручає роботу власному серверу.
Для прискорення пошуку IP-адрес DNS-сервери часто застосовують кешування
(на час від годин до декількох днів) відповідей, які проходять через них.
Нерекурсивна процедура:
1. DNS-клієнт звертається до кореневого DNS-сервера з вказівкою повного
доменного імені;
2. DNS-сервер відповідає клієнту, вказуючи адресу наступного DNS-сервера,
який виконує обслуговування домену верхнього рівня, заданого в наступній
старшій частині імені;
3. DNS-клієнт виконує запит наступного DNS-сервера, який його надсилає до
DNS-сервера потрібного піддомена і т. д., доти, доки не буде знайдено DNS-
сервер, який повністю відповідає запитуваному імені IP-адреси. Сервер дає
кінцеву відповідь клієнту.
Основою DNS є уявлення про ієрархічну структуру для створення БД і
 10

дозволу імен.
Кожен сервер, який відповідає за ім'я, може делегувати відповідальність за
подальшу частину домену іншого сервера (з адміністративної точки зору - інший
організації або людині), що дозволяє покласти відповідальність за актуальність
інформації на сервери різних організацій (людей), що відповідають тільки за «свою»
частину доменного імені.
Ключовими поняттями DNS є:
Домен ( Domain «область») - вузол в дереві імен, разом з усіма підлеглими
йому вузлами (якщо такі є), то є іменована гілка або піддерево в дереві імен.
Структура доменного імені відображає порядок проходження вузлів в ієрархії;
доменне ім'я читається зліва направо від молодших доменів до доменів вищого
рівня (в порядку підвищення значимості): вгорі знаходиться кореневий домен (який
має ідентифікатор «.» (точка)), нижче йдуть домени першого рівня (доменні зони),
потім - домени другого рівня, третього і т. д. (наприклад, для
адресиuа.wikipedia.org.домен першого рівня -org, другого -wikipedia, третього -uа).
DNS дозволяє не вказувати точку кореневого домена.
Піддомен ( Subdomain) - підлеглий домен (наприклад,wikipedia.org -
піддомен домену org, аuа.wikipedia.org – домену wikipedia.org). Теоретично такий
розподіл може досягати глибини 127 рівнів, а кожна мітка може містити до 63
символів, поки загальна довжина разом з точками не досягне 254 символів. Але на
практиці реєстратори доменних імен використовують більш суворі обмеження.
Наприклад, якщо у вас є домен виду mydomain.uа, ви можете створити для нього
різні піддомени виду mysite1.mydomain.uа,mysite2.mydomain.uаі т.д.
Ресурсний запис - одиниця зберігання і передачі інформації в DNS. Кожен
ресурсний запис має ім'я (тобто прив'язана до певного доменному імені, вузлу в
дереві імен), тип і поле даних , формат і зміст якого залежить від типу «Зона» -
частина дерева доменних імен (включаючи ресурсні записи ), що розміщується як
єдине ціле на деякому сервері доменних імен (DNS-сервері), а частіше - одночасно
на декількох серверах. Метою виділення частини дерева в окрему зону є передача
відповідальності за відповідний домен іншій особі або організації. Це називається
делегуванням. Як зв'язкова частина дерева, зона в середині теж є дерево. Якщо
розглядати простір імен DNS як структуру з зон, а не окремих вузлів/імен, теж
виходить дерево; виправдано говорити про батьківські і дочірні Зона - частина
дерева доменних імен (включаючи ресурсні записи), що розміщується як єдине ціле
на деякому сервері доменних імен (DNS-сервері), а частіше - одночасно на
декількох серверах. Метою виділення частини дерева в окрему зону є передача
відповідальності за відповідний домен іншій особі або організації. Це називається
делегуванням. Як зв'язкова частина дерева, зона в середині теж є дерево. Якщо
розглядати простір імен DNS як структуру з зон, а не окремих вузлів/імен, теж
виходить дерево; виправдано говорити про батьківські і дочірні зони, про старших
і підлеглих. На практиці більшість зон 0-го і 1-го рівня ('.', uа, com, ...) складаються
з єдиного вузла, якому безпосередньо підпорядковуються дочірні зони. У великих
корпоративних доменах (2-ва і більше рівнів).
DNS-сервер - спеціалізоване ПЗ для обслуговування DNS, а також
комп'ютер, на якому це ПЗ виконується. DNS-сервер може бути відповідальним за
певні зони і/або може перенаправляти запити вищим серверам.
 11

DNS-клієнт - спеціалізована бібліотека (або програма) для роботи з DNS.

У ряді випадків DNS-сервер виступає в ролі DNS-клієнта.
Авторитетність ( Authoritative) - ознака розміщення зони на DNS-сервері.
Відповіді DNS-сервера можуть бути двох типів: авторитетні (коли сервер заявляє,
що сам відповідає за зону) і неавторитетні ( Non-authoritative ), коли сервер
обробляє запит, і повертає відповідь інших серверів. У деяких випадках замість
передачі запиту далі DNS-сервер може повернути вже відоме йому (за запитами
раніше) значення (режим кешування).
DNS-запит ( DNS query) - запит від клієнта (або сервера) сервера. Запит
може бути рекурсивним або нерекурсивним.

Telnet
Telnet (Terminal network). Протокол прикладного рівня, призначений для здійснення
віддаленого доступу до пристроїв. Завданнями протоколу Telnet є виконання
скриптів і додатків на віддалених комп'ютерах, обробка даних, що надходять від
пристрою, і приведення їх до стандартного вигляду. Telnet надає повний доступ до
функціональних можливостей пристрою і може використовуватися для віддаленого
управління робототехнічними системами в IoT. Принцип роботи аналогічний
протоколу SSH з відзнакою лише в тому, що дані передаються в незашифрованому
вигляді.
Modbus
Modbus - комунікаційний протокол, заснований на технології master-slave.
Широко застосовується в промисловості для організації зв'язку між електронними
пристроями. Може використовувати для передачі даних через послідовні лінії
зв'язку RS-485, RS-422, RS-232, а також мережі TCP/IP (Modbus TCP ). Зазвичай в
мережі є тільки один клієнт, так званий «головний» (master) пристрій, і кілька
серверів - «підлеглих» (slaves) пристроїв. Головний пристрій ініціює транзакції
(передає запити). Підлеглі пристрої передають запитувані головним пристроєм
дані, або виконують запитувані дії. "Головний" може звертатися індивідуально до
підлеглого або ініціювати передачу широкомовного повідомлення для всіх
підлеглих пристроїв. Підлеглий пристрій формує повідомлення і повертає його у
відповідь на запит, адресований саме йому. При отриманні широкомовного запиту
відповідь не формується.Перевагами протоколу Modbus є відкритість і масовість
використання (безліч виробників випускають різні типи пристроїв, датчиків, що
підтримують даний протокол). Завданнями протоколу Modbus є контроль і
управління мережами, читання і запис даних в регістри зберігання, доступ до
файлів, діагностика стану пристроїв.
Найбільш важливі протоколи обміну повідомленнями, пропоновані в якості
основи нового покоління Інтернету речей (IoT) і, більш конкретно, промислових
інтернет - додатків (IIoT) є: BACnet, MQTT, CoAP, XMPP, STOMP, AMQP, CAP.

BACnet (Building Automation and Control Networks). Відкритий протокол

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

домашньої і промислової автоматизації, управління процесами, тестування і

вимірювань, міжмашинної взаємодії (М2М).
MQTT (Message Queue Telemetry Transport) - здійснює збір даних від безлічі
вузлів і передачу на сервер. Грунтується на моделі видавець-підписник з
використанням проміжного сервера - брокера (пріоритизація повідомлень,
формування черг і ін.). В якості транспорту - TCP. На основі MQTT був
сформований спеціалізований протокол MQTT-SN для сенсорних мереж.
CoAP (Constrained Application Protocol) - обмежений протокол з точки зору
користувача схожий на протокол HTTP, але відрізняється малим розміром
заголовків, що підходить для мереж з обмеженими можливостями, зокрема в таких
пристроях, як: вузли бездротових мереж датчиків, датчики низької потужності,
перемикачі, клапани та компоненти, які відслідковуються віддалено через мережі
Інтернет. В якості транспорту - UDP.
AMQP (Advanced Message Queuing Protocol) - відкритий стандарт протоколу
прикладного рівня для проміжного програмного забезпечення, орієнтованого на
обробку повідомлень. Семантика обміну повідомленнями налаштовується під
потреби конкретного проекту. «Брокер повідомлень», який здійснює
маршрутизацію, зазвичай гарантує доставку, розподіл потоків даних, черговість,
підписку на потрібні типи повідомлень. «Повідомлення» (message) відправляються
в «точку обміну». Точка обміну розподіляє повідомлення в одну або кілька «черг».
При цьому в точці обміну повідомлення не зберігаються. В якості транспорту -
TCP/UPD.
XMPP (Extensible Messaging and Presence Protocol) – відкритий протокол для
миттєвого обміну повідомленнями та інформацією про присутність між
користувачами в мережі Інтернет, в режимі близькому до режиму реального часу.
Стосовно до Інтернету речей XMPP забезпечує простий спосіб адресації пристроїв.
Для ідентифікації користувачів використовуються ідентифікатори Jabber ID, за
форматом схожі на адреси електронної пошти (наприклад, username@jabber.uа). У
протоколі XMPP застосовується текстовий формат XML (Мова XML призначена для
зберігання і передачі даних, а HTML же призначений для відображення даних). В
якості транспорту використовується протокол TCP. XMPP підтримує різні
комунікаційні моделі (запит-відповідь, публікація-підписка і інші).
STOMP – (Simple Text Oriented Message Protocol) - простий протокол обміну
повідомленнями, що передбачає широку взаємодію з багатьма мовами,
платформами і брокерами. Даний протокол підходить під шаблон "видавець-
підписник". Протокол в цілому схожий на HTTP, використовує транспорт TCP.
CAP (Common Alerting Protocol). Протокол загальної підтримки, попередньо
призначений для обміну повідомленнями. Використовується для передачі сигналів
про аварійні ситуації.
2.3.1 Протоколи HTTP/HTTPS, CoAP
HTTP (HyperText Transfer Protocol) - протокол передачі гіпертекстових
документів). Протокол прикладного рівня для передачі даних. Основою HTTP є
клієнт-серверна архітектура.
Для IoT більш безпечна реалізація є тільки HTTP клієнта на пристрої, тобто
пристрій може ініціювати з'єднання, а не отримувати. Завданнями протоколу
HTTP/HTTPS є надання доступу до внутрішніх веб-серверів контролерів/модулів,
 13

які перебувають в мережах, захищених брандмауерами або NAT, а також

завантажувати вміст веб-сторінок в ядро системи, моніторинг працездатності веб-
сервера.
HTTP припускає, що клієнтська програма - веб-браузер - здатна
відображати гіпертекстові веб-сторінки та файли інших типів у зручній для
користувача формі. Для правильного відображення HTTP дозволяє клієнтові
дізнатися мову та кодування символів веб-сторінки й/або запитати версію сторінки
в потрібних мові/кодуванні, використовуючи позначення із стандарту MIME.
Якщо в URL зі схемою http:// не вказаний порт, то за замовчуванням
береться 80.
Протокол HTTP заснований на механізмі «запит-відповідь». Коли клієнт
(зазвичай веб-браузер) відправляє запит веб-серверу, протокол HTTP визначає
типи повідомлень для цієї взаємодії.
Кожен запит/відповідь складається з трьох частин:
1. стартовий рядок;
2. заголовки;
3. тіло повідомлення, що містить дані запиту, запитаний ресурс або
опис проблеми, якщо запит не виконано.
Обов'язковим мінімумом запиту є стартовий рядок. Починаючи з HTTP/1.1
обов'язковим став заголовок Host: (щоб розрізнити кілька доменів, які мають одну й
ту ж IP-адресу).
1. Стартові рядки розрізняються для запиту й відповіді.
Рядок запиту виглядає так:

‹Метод› ‹URI› HTTP/‹Версія›

де ‹Метод›, як правило вказуються три основні типи повідомлень: GET,

POST і PUT.
GET – це запит даних клієнтом. Клієнт (веб-браузер) відправляє
повідомлення GET веб-серверу, щоб запросити HTML -сторінки. Коли сервер
отримує запит GET, він повертає рядок стану «HTTP/1.1 200 OK» і своє
повідомлення. Відповідь сервера може містити запрошений HTML-файл (якщо
він доступний) або повідомлення про помилку, наприклад: «The location of the
requested file has changed».
Згідно зі стандартом HTTP, запити типу GET вважаються ідемпотентними -
багатократне повторення одного і того ж запиту GET повинне приводити до
однакових результатів (за умови, що сам ресурс не змінився за час між запитами).
Це дозволяє кешувати відповіді на запити GET.
Запити POST і PUT використовуються для відправки файлів даних
на веб-сервер.
Запит POST передає призначені для користувача дані (наприклад, з HTML-
форми) заданому ресурсу. Наприклад, в блогах відвідувачі зазвичай можуть
вводити свої коментарі до записів в HTML-форму, після чого вони передаються
серверу методом POST, і він поміщає їх на сторінку. При цьому передані дані (у
прикладі з блогами — текст коментаря) включаються в Тіло запиту (Request body).
На відміну від методу GET, метод POST не вважається ідемпотентним, тобто
багатократне повторення одних і тих же запитів POST може повертати різні
 14

результати (наприклад, після кожного відправлення коментаря з'являтиметься

одна копія цього коментаря).
Запит PUT відправляє на веб-сервер ресурси або вміст. Наприклад,
якщо користувач намагається відправити файл або зображення на веб-сайт,
клієнт відправляє серверу PUT з вкладеним файлом або зображенням.

Рис. 2.1. Протокол з використанням GET (Ввід https://www.cisco.com/ в

адресній стрічці браузера створює повідомлення «GET» протоколу HTTP)

Методи, які майже не використовують:

HEAD - аналогічний методу GET, за винятком того, що у відповіді сервера
відсутнє тіло. Це корисно для витягання мета-інформації, заданої в заголовках
відповіді, без пересилання всього вмісту.
PATCH - Завантажує певну частину ресурсу на сервер.
DELETE Видаляє вказаний ресурс.
TRACE Повертає отриманий запит так, що клієнт може побачити, що
проміжні сервери додають або змінюють в запиті.
Рядок Відповіді з сервера:
Перший рядок відповіді виглядає так:
HTTP/‹Версія› ‹Код статусу› ‹Опис статусу›
Коди статусу:
1хх — інформаційний: запит прийнятий, продовжуй процес.
2хх — успіх: дія була успішно передана, зрозуміла, та прийнята.
3хх — перенаправлення: наступні дії мають бути успішно виконані для
реалізації запиту.
4хх — помилка клієнта: запит містить синтаксичні помилки або не може бути
виконаний.
 15

5хх — помилка сервера: сервер не зміг виконати правильно сформований

запит.
Найбільш поширені статуси:
200 OK — запит виконано успішно.
301 Moved Permanently — ресурс переміщено.
403 Forbidden — доступ до запитаного ресурсу заборонений.
404 Not Found — ресурс не знайдений.
503 Service Unavailable — сервіс недоступний.
2. Заголовки
Заголовки HTTP — це рядки, кожен з яких складається з імені параметра,
за яким слідує двокрапка і його значення. Вони несуть інформацію для браузера
або для серверних програм. Між заголовками і тілом обов'язково повинен бути
порожній рядок.
Приклад HTTP діалогу:
Запит

GET /wiki/HTTP HTTP/1.1

Host: uk.wikipedia.org
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7) Gecko/20070914
Firefox/2.0.0.7
Connection: close

Відповідь

HTTP/1.0 200 OK
Server: Apache
Content-Language: uk
Content-Type: text/html; charset=utf-8
Content-Length: 1234
(пустий рядок)
(далі йде текст html-сторінки)

Важливо: HTTP-заголовок відокремлюється від повідомлення пустою

стрічкою. Довжина повідомлення в байтах вказується в параметрі Content-
Length .
В першій стрічці відповіді вказується протокол, код відповіді.

Наприклад, на рис. 2.3 зображений процес отримання веб-сторінки з веб-

сервера. Після того, як Андрій відкрив браузер і ввів ім'я сайту в адресному рядку,
браузер посилає запит на першу сторінку (найчастіше файл з першою сторінкою
називається index.html) за допомогою протоколу HTTP. Як ми бачимо, запит
знаходиться в заголовку рівня додатків.
 16

Рис. 2.3 Обмін даними на рівні додатків

Сервер отримує запит і починає передачу сторінки, при цьому у нас є заголовок з
відповіддю (в заголовку повертається код 200) на запит - ОК, і дані, тобто веб
сторінка. На даному малюнку веб-сторінка не помістилася в одне повідомлення,
отже, було направлено додаткове повідомлення. Розміри переданих повідомлень
ми розглянемо далі. Також можливий такий варіант, що веб-сторінка заблокована
для перегляду або просто недоступна,
Заголовки є на кожному рівні мережевої моделі TCP/IP. Найчастіше вони
прикріплюються до деяких даних (в прикладі вище заголовок рівня додатків
прикріплений до web-сторінки). Простіше кажучи, він є таким собі набором
налаштувань і полів, за допомогою яких відбувається спілкування на певному рівні
мережевої моделі (на кожному рівні свій заголовок).
Не дивлячись на те, що протокол HTTP досить гнучкий, він не є безпечним.
Повідомлення запитів передаються серверу відкритим текстом, який може
бути перехоплений і прочитаний. Аналогічним чином, відповіді сервера
(звичайно це HTML – сторінки) також передаються в незашифрованому виді.
Для захищеного двостороннього обміну даними з веб-серверами в Інтернеті
використовується протокол HTTPS. HTTPS дозволяє використовувати
автентифікацію і шифрування для захисту даних, що пересилаються між
клієнтом і сервером.

HTTPS
HTTPS ( HTTP Secure) — схема URI, що синтаксично ідентична http: схемі,
яка зазвичай використовується для доступу до ресурсів Інтернет. Використання
https: URL вказує, що протокол HTTP має використовуватися, але з іншим портом
за замовчуванням (443) і додатковим шаром шифрування/автентифікації між HTTP
і TCP.
Протокол HTTPS визначає додаткові правила передачі даних між
прикладним і транспортним рівнем. У протоколах HTTPS і HTTP процеси
«клієнт просить – сервер відповідає» аналогічні, але потік даних шифрується
за допомогою криптографічного протоколу SSL (Secure Sockets Layer, рівень
захищених сокетів), який забезпечує встановлення безпечного з'єднання між
 17

клієнтом і сервером перед початком передачі по мережі.

Протокол SSL складається з двох підпротоколів: протокол SSL запису і
рукостискання. Протокол SSL запису визначає формат, який використовується для
передачі даних. Протокол SSL включає рукостискання з використанням протоколу
SSL запису для обміну серіями повідомлень між сервером і клієнтом, під час
встановлення першого з'єднання. Для роботи SSL потрібно, щоб на сервері був
SSL-сертифікат.
SSL надає канал, що має три основні властивості:
 Автентифікація. Сервер завжди автентифікований, в той час як клієнт
автентифікований в залежності від алгоритму.
 Цілісність. Обмін повідомленнями включає в себе перевірку цілісності.
 Конфіденційність каналу. Шифрування використовується після
встановлення з'єднання і використовується для всіх наступних повідомлень.
Оскільки HTTPS це фактично HTTP, який передається через SSL, то майже
всі його основні елементи шифруються: URL-запити, включаючи шлях та назву
ресурсу (сторінки), параметри запиту, заголовки та куки, які часто містять
ідентифікаційні дані про користувача. Не шифруються: назва або адреса хоста
(веб-сайту) та порт, оскільки вони використовуються транспортним протоколом
TCP/IP для встановлення з'єднання.
Шифрування гарантує помірний захист від підслуховування та від нападу
«людина посередині» (man-in-the-middle), за умови коректних налаштувань та
підпису сертифікату авторизованим центром сертифікації.
Щоб підготувати веб-сервер для прийняття https транзакцій адміністратор
повинен створити сертифікат з відкритим ключем для веб-сервера. Ці сертифікати
можуть бути створені на UNIX сервері такими програмами, як наприклад OpenSSL.
Цей сертифікат повинен бути підписаний уповноваженим на видачу сертифікатів
(certificate authority), який засвідчує, що отримувач сертифікату — саме той, про
кого йдеться у сертифікаті. Браузери розповсюджуються з сертифікатами центрів
сертифікації верхнього рівня, що дозволяє браузерові перевіряти сертифікати, які
були підписані цими центрами.
Протокол HTTPS особливо важливий у незахищених мережах (таких як
публічні Wi-Fi точки доступу), оскільки будь-хто в локальних мережах може
аналізувати трафік та перехоплювати чи змінювати інформацію, не захищену
HTTPS. Це означає, що гіпотетичний зловмисник може потенційно красти приватні
дані користувача, отримувати доступ до облікового запису, вставляти шкідливий
програмний код чи посилання на програмне забезпечення у сторінки, що
надсилаються користувачеві у відповідь на його запити, тощо.

Протокол із обмеженим ресурсами CoAP

CoAP (Constrained Application Protocol) - протокол із обмеженим ресурсами.
з точки зору користувача схожий на протокол HTTP, але відрізняється малим
розміром заголовків, що підходить для мереж з обмеженими можливостями,
зокрема в таких пристроях, як: вузли бездротових мереж датчиків, датчики низької
потужності, перемикачі, клапани та компоненти, які відслідковуються віддалено
через мережу Інтернет. Такі пристрої використовуються в області Інтернету речей,
а породжуваний ними інформаційний обмін називається міжмашинною взаємодією
 18

(М2М). Часто подібні пристрої називають пристроями з обмеженими ресурсами.

Вони зазвичай мають обмежений енергоресурс, невеликий обсяг пам'яті і невисоку
потужність, тому в роботі з ними важливо забезпечувати низькі енерговитрати,
використовувати передачу повідомлень малого обсягу. Протокол CoAP забезпечує
взаємодію цих пристроїв, щоб виконувати всі необхідні вимоги. Мережа, в якій
працюють такі пристрої, називають мережею з обмеженими ресурсами.
В якості транспортного протоколу CoAP за замовчуванням використовує не
TCP, а UDP і працює на порту 5683.
Використовує архітектуру клієнт-сервер і підходить для передачі інформації
про стан вузла на сервер.
З точки зору архітектури, сервер CoAP буде встановлений на кінцевому
вузлі, який може бути датчиком. З іншого боку, клієнт CoAP повинен бути
встановлений на контролері, який керує кількома кінцевими вузлами.

Використання протоколу СоАР

Розглянемо такий пристрій з обмеженими ресурсами, як датчик. У
користувача в приміщенні може бути встановлено кілька датчиків, управляти якими
він може або через мережу Інтернет, або безпосередньо через мережу з
обмеженими ресурсами в тому випадку, якщо на його пристрої встановлено
додаток, що працює по протоколу СоАР (рис. 2.2.).

СоАР-давачі
 19

Рис. 2.4. Взаємодія з використанням протоколу СоАР

На рис. 2.4. область "А" показує приклад взаємодії користувацького

пристрою (HTTP-клієнта) з СоАР -датчиком через мережу Інтернет. HTTP-клієнт
генерує HTTP-запити і відправляє їх на сервер, який за відсутності необхідної
інформації на отриманий запит звертається до CoAP-проксі. Тут CoAP-проксі - це
пристрій, що з'єднує мережу Інтернет на основі протоколу httр і мережу з
обмеженими ресурсами, що підтримує протокол CoAP. Проксі перетворює
повідомлення однієї мережі (протокол HTTP) в повідомлення, зрозумілі для іншої
(протокол CoAP).
Якщо запит від користувацького пристрою відразу потрапляє в мережу з
протоколом CoAP, то він надходить на CoAP - датчик (на рисунку - область "Б"). При
такій взаємодії сервер отримує всі запити і далі індивідуально однонаправлено
посилає відповідному пристрою запит який до нього відноситься і очікує від нього
відповідь.
Особливості CoAP
Структура протоколу CoAP була розроблена відповідно до REST-
архітектури. REST (Representational State Transfer) - це вид архітектури, що
дозволяє будувати додатки, в основі яких лежатиме наступна група методів:
GET - виконує пошук ресурсів і надає інформацію, яка відповідає ресурсу,
зазначеному на засланні URI (Uniform Resource Identifier), де ресурс - це джерело
даних, яким, наприклад, може бути датчик;
PUT - задає нову дію над ресурсом;
POST - відповідає за зміни дії над ресурсом;
DELETE - служить для видалення активованих можливостей ресурсу.
У квітні 2017 вийшов документ RFC, що розширює протокол CoAP новими
двома методами:
FETCH - виконує надання часткової інформації про ресурс за параметрами
в запиті;
PATCH - відповідає за часткову зміну дії над ресурсом.
Протокол був доповнений цими методами, тому що виникла необхідність
деяких додатків отримувати доступ або змінювати в ресурсі інформацію не
повністю, а взаємодіяти тільки з певною його складовою.
REST: архітектурні принципи
REST визначає цілий ряд граничних умов.
 Існує єдиний інтерфейс для кожного ресурсу, включаючи дієслова /
методи GET, PUT, POST, DELETE.
 REST використовує взаємодію клієнт-сервер, де клієнт і сервер
взаємодіють через інтерфейси, які роблять їх незалежними від деталей реалізації
комунікаційного партнера.
 Основною особливістю REST є його безгромадянство. Зв'язки не
пам'ятають жодної історії. Тому інформація про стан повинна бути надіслана
клієнтом при кожному виклику, бо на сервері не може зберігатися інформація про
сеанс.
 Кешування використовується для зберігання багаторазової
запитуваної інформації для підвищення продуктивності.
 20

Обмін повідомленнями протоколу СОАР

Рис. 2.5 Без окремої відповіді З окремою відповіддю

Існує два режими рис. 2.5, в яких повідомлення протоколу CoAP

обмінюються між клієнтом CoAP та сервером CoAP, а саме без окремої відповіді та
з окремою відповіддю.
З окремою відповіддю сервер повідомляє клієнта про отримання запиту на
повідомлення. Це збільшить час обробки, але допоможе уникнути зайвих повторних
передач.
CoAP IoT - ненадійний протокол через використання UDP. Отже,
повідомлення CoAP надходять не упорядковано або загубляться, коли прибудуть
до пункту призначення. Щоб зробити CoAP надійним протоколом, має бути
включена експоненціальна функція повторної передачі.

Формат заголовка повідомлень CoAP

У протоколі СоАР визначено всього чотири види повідомлень: Confirmable,
Non-confirmable, Acknowledgement, Reset. Всі повідомлення кодуються в бінарному
вигляді.
Повідомлення починається з заголовка, з фіксованим розміром в 4 байта, за ним
слідує маркер, опції (параметри) і корисне навантаження, яке займає всю решту
датаграми.
 21

Поля в повідомленні визначаються наступним чином:

Версія (Версія) (Ver) - двобітне ціле число, що вказує на номер версії CoAP.
На даний момент існує тільки одна версія протоколу.
Тип (Тип) (Т) - двобітне ціле число. Визначає тип повідомлення. У COAP
використовується чотири типи повідомлень:
• Confirmable (CON) - повідомлення, що містить запит або відповідь, яка
потребує підтвердження і вважається надійним. Кожне повідомлення Confirmable
викликає одне повідомлення-відповідь про підтвердження або скидання.
• Non-confirmable (NON-CON) - повідомлення, що містить запит або
відповідь, що не вимагає підтвердження і надійної передачі, так як передається
регулярно (наприклад, покази від датчика);
• Acknowledgement (ACK) - повідомлення, яке підтверджує, що прийшло
повідомлення Confirmable.
• Reset (R) - повідомлення скидання, яке вказує на те, що конкретне
повідомлення (Confirmable або Non-confirmable) було отримано, але деяка частина
тексту відсутня і неможливо правильно його обробити. Така ситуація зазвичай
виникає, коли приймаючий вузол перевантажений.
Довжина маркера (Token Length) (TKL) – чотирьохбітне ціле число. Вказує довжину
поля маркера (Token) змінної довжини (0-8 байт). Маркер використовується для
узгодження запитів із відповідями. Довжини від 9 до 15 байт зарезервовані.

Код (Code) – восьмибітове ціле число, ділиться на трибітний і п’ятибітний клас.

Використовується для вказівки методу запиту у запитах та коду відповіді у
відповідях.

Поле "код" записується, як "c.dd", де "с" - це цифра від 0 до 7 для трибітного

підполя і "dd" - дві цифри в діапазоні від 00 до 31 для п’ятибітного підполя.

• Код 0.00 вказує на порожнє повідомлення.

• Код 0.01-0.31 вказує на запит.
• Код 1.00-1.31 зарезервований.
• Код 2.00-2.31 вказує на успішну відповідь.
• Код 3.00-3.31 зарезервований.
• Код 4.00-4.31 вказує на помилку клієнта.
• Код 5.00-5.31 вказує на помилку сервера.
• Код 6.00-7.31 зарезервований.

Значення "dd" - це фіксовані табличні величини, які вказують в разі, якщо

повідомлення - запит на метод запиту (наприклад, 0.01 - це запит GET, 0.02 - це
запит POST); в разі, якщо повідомлення - відповідь, вказують на код відповіді
(наприклад, 2.05 - це відповідь, що містить запитувану інформацію (Content), 4.04 -
це помилка, яка виникає, коли запитуваний пристрій відсутній або тимчасово
недоступний (Not Found)). Всю таблицю значень поля Code можна подивитися в
 22

документі RFC7252, розділ 12.1.2.

Ідентифікатор повідомлення (Message ID) - шістнадцятибітове ціле число,
яке є унікальним ідентифікатором для повідомлення. Message ID ідентифікує
повідомлення, щоб визначити, на який запит прийшла інформація або помилка.
CoAP-пристрій, відправляючи повідомлення Confirmable або Non-confirmable,
випадковим чином генерує значення ідентифікатора для цього повідомлення. У
відповідь повідомленнях Acknowledgement- або Reset-ідентифікатори будуть ті ж,
що і в повідомленні, на яке вони відповідають.
Значення маркера (Token), яке може становити від 0 до 8 байтів, як
зазначено в полі TKL. Значення маркера випадковим чином генерується пристроєм
CoAP і використовується в межах однієї сесії для встановлення відповідності запиту
з відповіддю, тобто відбувається групування повідомлень по ланцюжку "запит-
відповідь".
Параметри, опція (Options), в яких описуються різні параметри повідомлень.
Наприклад, є Max-Age Option, встановлює максимальний час зберігання інформації
в тимчасовій пам'яті, за замовчуванням 60 сек. Content-Format Option, задається у
вигляді числа, яке встановлює формат подання корисного навантаження: значення
0 вказує на те, що корисне навантаження буде текстове, значення 41 вказує на те,
що корисне навантаження буде в форматі xml.
Далі йде двійкове число 11111111 (0xFF), яке використовується як роздільник
між полем «Опція» та полем «Корисне навантаження»
Корисне навантаження - це поле, яким завершується формат повідомлення
(Payload), в якому міститься інформація, що запитується.

Приклад сценарію взаємодії.

Розглянемо приклад того, як відправляються запити і які повідомлення (їх
зміст) будуть при цьому відправлені. На рис. 2.6. показаний приклад взаємодії між
HTTP-клієнтом і СоАР-датчиком і трансляцією їх повідомлень через CoAP-проксі.
Нехай користувач запитує покази освітленості кухні, які визначаються датчиком
світла.
HTTP-клієнт посилає повідомлення GET, в якому міститься запит на
отримання рівня освітленості. Повідомлення приходить на проксі, який перетворює
HTTP-запит в запит по протоколу CoAP. Далі інформація про вимогу параметра
освітленості передається в повідомленні CON, і йому присвоюється ідентифікатор
повідомлення; такий же ідентифікатор міститься у відповідному повідомленні ACK,
яке несе в собі необхідну інформацію.
 23

Рис. 2.6. Сценарій взаємодії між HTTP і СоАР

Розглянемо детально формат повідомлення у відповідь ACK на запит (рис.

2.7.). В поле "тип" вказується, що передається повідомлення ACK (2). Далі йде 1
байт, який говорить про наявність маркера, за ним слідує код, який вказує на успішну
відповідь (2.05).

Рис. 2.7. Формат повідомлення Acknowledgement

На рис. 2.8. показаний приклад роботи CoAP-клієнта і СоАР-датчика. В

даному прикладі розглянуто випадок, коли у відповідь повідомлення від CoAP-
клієнта втрачається, тоді буде проведена повторна відправка запиту після
завершення таймера очікування відповіді; значення таймера дорівнює 1 сек, згідно
RFC 6298.
 24

Рис. 2.8. Сценарій взаємодії CoAP-клієнта і СоАР-датчика

Слід зазначити, що протокол CoAP підтримує можливість послати запит

відразу групі пристроїв, реалізуючи таким чином багатоадресну розсилку (multicast).
СoAP-пристрої з обмеженими ресурсами можуть об'єднаються в групи або
однаковою функцією пристроїв (зняття показів світла або температури), або за
місцем розташування (зняття показів в певній кімнаті, поверсі будівлі).

Рис. 2.9. Сценарій багатоадресної розсилки

Користувача пристрій відправляє запит на широкомовний IP-адрес,

призначений для групи, такий запит досягає всіх датчиків, які налаштовані на таку
адресу рис.2.9. У сценарії CoAP датчики 1, 3 і 5 налаштовані на IP-адресу групи,
тому вони приймають запит і відповідають: CoAP-датчик 1 посилає успішна
відповідь (2.05), і він досягає сервера; CoAP-датчик 3 посилає успішна відповідь,
але при передачі він втрачається; CoAP-датчик 5 не може дати відповідь, так як
тимчасово недоступний (4.04); залишилися CoAP-датчики 2 і 4 не налаштовані на
отримання даного запиту і просто його відкидають.

2.3.2. ПРОТОКОЛ MQTT

На відміну від протоколу CoAP протокол MQTT є стандартизований в 2014

році і вже встиг набути широкого поширення в промисловості і IoT. Він був
спеціально розроблений максимально компактним, для нестабільних інтернет-
каналів і малопотужних пристроїв, і дозволяє гарантовано доставляти
повідомлення в разі втрати пакетів і обривів зв'язку. На сьогодні одним з
популярних відкритих протоколів зв'язку для Розумного будинку є MQTT.
MQTT (Message Queue Telemetry Transport) - спрощений мережевий
протокол обміну даними та створений для передачі даних на віддалених локаціях,
де потрібно невеликий розмір коду і є обмеження по пропускній здатності каналу. В
 25

його основі лежить проста ідея перенесення ресурсозатратної частини системи на

один елемент у якого ці ресурси є. При цьому всі інші учасники системи майже
повністю звільнені від роботи, що дозволяє їм економити ресурси. Реалізовано це
наступним чином: пристрої, які хочуть передати повідомлення (під назвою видавці
в термінах MQTT), відправляють його серверу ( брокеру ), пристрої які хочуть
отримати повідомлення ( передплатники ), також підключаються до брокера і
отримують повідомлення від нього. Всю обробку повідомлень бере на себе MQTT-
брокер. Даний підхід показав себе дуже добре і ефективно в таких завданнях, як,
наприклад, збір даних, телеметрія і управління простими пристроями.
Протокол по суті справи описує лише мову, а не спосіб доставки даних.
MQTT вимагає наявність сервера - брокера, який об'єднує під'єднаних
пристроїв у мережу. Самі ж пристрої при підключенні підписуються на топіки в яких
надсилаються дані і брокер відсилає тільки ті топіки пристрою, які йому потрібні.
Перша версія протоколу MQTT була розроблена доктором Енді Станфорд-
Кларком (IBM) та Арлен Ніппер (Arcom) 1999 року і опублікована під роялті-фрі
ліцензією. Специфікація MQTT 3.1.1 була стандартизована консорціумом OASIS в
2014 році.
MQTT орієнтований для обміну повідомленнями між пристроями за
принципом видавець-передплатник в системах M2M (Машинно-Машинна
взаємодія) та IIoT (Промисловий Інтернет речей).
Можливості протоколу MQTT:
 Простий у використанні.
 Протокол є програмним блоком без зайвої функціональності, що може бути
легко вбудований в будь-яку складну систему;
 Легкий у адмініструванні;
 компактні повідомлення
 Зручний для більшості рішень з датчиками. Дає можливість пристроям
виходити на зв'язок і публікувати повідомлення, які не були заздалегідь відомі або
визначені;
 Робота в умовах нестабільного зв'язку на лінії передачі даних
 Підтримка декількох рівнів якості обслуговування (QoS)
 Легка інтеграція нових пристроїв

Протокол MQTT працює на прикладному рівні поверх TCP/IP і використовує

за замовчуванням порт 1883 (8883 при підключенні через SSL).
SSL (Secure Sockets Layer — рівень захищених сокетів) — криптографічний
протокол, який забезпечує встановлення безпечного з'єднання між клієнтом і
сервером.
Протокол MQTT вимагає обов'язкової наявності брокера даних. Це
центральна ідея технології.
В мережі на базі протоколу MQTT розрізняють 3 об'єкти (рис. 2.10):
1) видавець (publisher) - MQTT-клієнт, який при виникненні певних подій передає
інформацію про нього в брокер;
 26

2) брокер (broker) - MQTT-сервер, який приймає інформацію від видавців і передає

її відповідним передплатникам, в складних системах може виконувати також різні
операції, пов'язані з аналізом і обробкою даних, що надійшли;
3) передплатник (subscriber) - MQTT-клієнт, який після підписки у відповідного
брокера більшу частину часу «слухає» його і постійно готовий до прийому і обробки
вхідного повідомлення від брокера.
Зауважимо, що пристрої IoT (видавець) першими встановлюють зв'язок з
брокером і можуть знаходиться за трансляторами мережевих адрес (NAT-ами) і не
мати статичних IP- адрес.

Рис. 2.10 - Мережа на базі протоколу MQTT

Отримати можливість підключитися до сервера-брокера можна двома
способами: скористатися безкоштовними брокерами або підняти свій власний
сервер. Перший варіант найпростіший.На сьогодні популярними MQTT брокерами
є CloudMQTT, Mosquitto MQTT, Azure MQTT. Для домашнього використання
популярним є брокер CloudMQTT, але він має обмеження по кількості пристроїв і
запитів. При реєстрації видається логін, пароль, сервер до якого потрібно робити
конект, тип з'єднання (з/без ssl).
Обмін повідомленнями в протоколі MQTT здійснюється між клієнтом (client),
який може бути видавцем або підписником (publisher/subscriber) повідомлень, і
брокером (broker) повідомлень (наприклад, Mosquitto MQTT) рис.2.11.

Рис. 2.11. Схема простої взаємодії між передплатником, видавцем і брокером

Видавець відправляє дані на MQTT брокер, вказуючи в повідомленні певну

тему, топік (topic). Передплатники можуть отримувати різні дані від безлічі видавців
залежно від підписки на відповідні топіки.
Передплатники можуть отримувати різні дані від безлічі видавців залежно від
підписки на відповідні топіки.
 27

Семантика Топіків
Через MQTT зручно обмінюватись повідомленнями, так як іх топіки мають
певну сематику, зрозумілу більшості людей. Топіки представляють собою символи
з кодуванням UTF-8 (кодування, що реалізовує представлення Юнікоду). Ієрархічна
структура топіків має формат «дерева», що спрощує їх організацію та доступ до
даних. Топіки складаються з одного або декількох рівнів, які розділені між собою
символом «/».
Приклад топік в якому датчик температури, розташований в спальній кімнаті
публікує дані брокеру:
/ Home/living-space/living-room1/temperature

Передплатник може так само отримувати дані відразу з декількох топіків,

для цього існують шаблони (wildcard).
Шаблони поділяються:
 однорівневі
 багаторівневі.
Для більш простого розуміння розглянемо в прикладах кожен з них:
Однорівневий wildcard. Для його використання застосовується символ «+»
Наприклад, нам необхідно отримати дані про температури у всіх спальних кімнатах:
/ home/living-space/+/temperature
В результаті отримуємо дані з топіків:
/ Home/living-space/living-room1/temperature
/ Home/living-space/living-room2/temperature
/ Home/living-space/living-room3/temperature

Багаторівневий wildcard. Для його використання застосовується символ «#»

Наприклад, щоб отримати дані з різних датчиків всіх спалень в будинку:
/ home/living-space/#
В результаті отримуємо дані з топіків:
/ Home/living-space/living-room1/temperature
/ Home/living-space/living-room1/light1
/ Home/living-space/living-room1/light2
/ Home/living-space/living-room2/temperature
/ Home/living-space/living-room2/light1

Структура MQTT повідомлень

MQTT повідомлення складається з декількох частин:
• Фіксований заголовок (є у всіх повідомленнях)
• Змінний заголовок (присутній тільки в певних повідомленнях)
• Дані корисного навантаження присутній тільки в певних повідомленнях)
 28

фіксований заголовок

Message Type - це тип повідомлення, наприклад: CONNECT, SUBSCRIBE,

PUBLISH і інші, таблиця 2.2.
Flags specific to each MQTT packet - ці 4 біти відведені під допоміжні прапорці,
наявність і стан яких залежить від типу повідомлення.
Remaining Length - представляє довжину поточного повідомлення (змінний
заголовок + дані), може займати від 1 до 4 байти.

Всього в протоколі MQTT існує 15 типів повідомлень:

Таблиця 2.2.
Тип повідомлення значення напрямок передачі опис

Reserved 0000 (0) немає зарезервований

Запит клієнта на підключення до

CONNECT 0001 (1) Клієнт→Сервер
сервера

CONNACK 0010 (2) Клієнт←Сервер Підтвердження успішного підключення

PUBLISH 0011 (3) Клієнт↔Сервер публікація повідомлення

PUBACK 0100 (4) Клієнт↔Сервер підтвердження публікації

PUBREC 0101 (5) Клієнт↔Сервер публікація отримана

PUBREL 0110 (6) Клієнт↔Сервер Дозвіл на видалення повідомлення

PUBCOMP 0111 (7) Клієнт↔Сервер публікація завершена

SUBSCRIBE 1000 (8) Клієнт→Сервер Запит на підписку

SUBACK 1001 (9) Клієнт←Сервер Запит на підписку прийнятий

UNSUBSCRIBE 1010 (10) Клієнт→Сервер Запит на відписку

UNSUBACK 1011 (11) Клієнт←Сервер Запит на відписку прийнятий

PINGREQ 1100 (12) Клієнт→Сервер PING запит

PINGRESP 1101 (13) Клієнт←Сервер PING відповідь

Повідомлення про відключення від

DISCONNECT 1110 (14) Клієнт→Сервер
сервера

Reserved 1111 (15) зарезервований

ПРАПОРЦІ
 29

Чотири старших біти першого байта фіксованого заголовка відведені під

спеціальні прапори:

DUP - прапорець дубліката встановлюється, коли клієнт або MQTT брокер

здійснює повторну відправку пакета (використовується в типах PUBLISH,
SUBSCRIBE, UNSUBSCRIBE, PUBREL). При встановленому прапорці змінний
заголовок повинен містити Message ID (ідентифікатор повідомлення). DUPlicate -
дублювання повідомлення. Цей прапор вказує одержувачу, що отримане їм
повідомлення передається повторно і, можливо, вже було отримано ним раніше.
Цей прапор грає важливу роль при передачі інформації по ненадійних каналах, де
можлива втрата сигналу.
QoS – рівень якості обслуговування (0, 1, 2) при передачі повідомлень - це
угода між відправником повідомлення та одержувачем повідомлення, що визначає
гарантію доставки для конкретного повідомлення.
В MQTT є 3 рівня QoS:
 Не більше одного разу (0)
 Принаймні один раз (1)
 Точно один раз (2)
При використанні QoS в MQTT потрібно розглянути дві сторони доставки
повідомлень:
1. Доставка повідомлень від клієнта-видавця до брокера.
2. Доставка повідомлень від брокера до підписаного клієнта
(передплатника).

Наприклад при якості обслуговування QoS 0 - не більше одного. Видавець

публікує повідомлення (PUBLISH) на брокері, а брокер публікує його для
передплатника. Видавець не вимагає, щоб це повідомлення було гарантовано
передано передплатнику (без гарантії доставки), та не відстежується видавцем.
Описаний сценарій використовується для тих випадків, коли втрати даних не
критичні. Наприклад, при постійному моніторингу температури, коли втрата
одиничного вимірювання не відіграє суттєвої ролі в загальній картині. Це - метод
«відправив і забув»

QoS 1 - хоча б один. Видавець публікує повідомлення на брокері (PUBLISH).

Брокер зберігає це повідомлення і публікує його для підписника. Тільки після того,
 30

як повідомлення буде опубліковано для підписника, брокер відсилає підтвердження

публікації видавцеві (PUBACK). Поки видавець не отримає підтвердження публікації
підписнику, дана публікація буде надсилатися брокеру і далі підписнику. Таким
чином, підписник повинен отримати дане повідомлення як мінімум один раз.

QoS 2 - гарантовано один. Рівень QoS забезпечує вищу гарантію доставки

повідомлень за рахунок використання додаткових процедур підтвердження і
завершення публікації (PUBREC, PUBREL, PUBCOMP). Сценарій застосуємо для
ситуацій, коли потрібно виключити будь-які втрати і дублювання даних від датчиків.
Наприклад, коли від отриманого повідомлення спрацьовує сигналізація, виклик
екстрених служб.

RETAIN. Даний прапорець служить для індикації збереження останнього

прийнятого брокером повідомлення. Тобто прапорець RETAIN=1 в повідомленні
PUBLISH від видавця повідомляє брокеру про те, що повідомлення по цій темі
потрібно зберегти і, коли новий підписник приєднається до теми, відправити йому
це повідомлення. Використовується тільки в повідомленнях з типом PUBLISH.
Змінний заголовок
Змінний заголовок міститься в деяких заголовках.
У ньому містяться такі дані:
 Packet identifier - ідентифікатор пакета, присутній у всіх типах повідомлень,
крім: CONNECT, CONNACK, PUBLISH (з QoS <1), PINGREQ, PINGRESP,
DISCONNECT
 Protocol name - назва протоколу (тільки в повідомленнях типу CONNECT)
 Protocol version - версія протоколу (тільки в повідомленнях типу CONNECT)
 Connect flags - прапорці вказують на поведінку клієнта при підключенні
 31

User name - при наявності цього прапорця в «навантаження» має бути

вказано ім'я користувача (використовується для аутентифікації клієнта)
Password - при наявності цього прапорця в «навантаження» повинен бути
вказаний пароль (використовується для аутентифікації клієнта)
Will Retain - при установці в 1, брокер зберігає у себе Will Message.
Will QoS - якість обслуговування для Will Message, при встановленому
прапорці Will Flag, Will QoS і Will retain є обов'язковими.
Will Flag - при встановленому прапорі, після того, як клієнт відключиться від
брокера без відправлення команди DISCONNECT (у випадках непередбачуваного
обриву зв'язку і т.д.), брокер сповістить про це всіх підключених до нього клієнтів
через так званий Will Message.
Clean Session - очистити сесію. При встановленому «0» брокер збереже
сесію, всі підписки клієнта, а так же передасть йому всі повідомлення з QoS1 і QoS2,
які були отримані брокером під час відключення клієнта, при його наступному
підключенні. Відповідно при встановленій «1», під час наступного з'єднання клієнту
буде необхідно заново підписуватися на топіки.
• Session Present - застосовується в повідомленні з типом CONNACK.
Якщо брокер приймає підключення з Clean Session = 1 він повинен встановити «0»
в біт Session Present (SP). Якщо брокер приймає підключення з Clean Session = 0,
то значення біта SP залежить від того, зберігав чи брокер раніше сесію з цим
клієнтом (якщо так, то в SP виставляється 1 і навпаки). Тобто цей параметр
дозволяє клієнту визначити чи була збережена брокером попередня сесія.
• Connect Return code - якщо брокер з якихось причин не може прийняти
правильно сформований CONNECT пакет від клієнта, то в другому байті CONNACK
пакета він повинен встановити відповідне значення з нижчезазначених у списку
таблиці 2.3
• Topic Name - назва топіка.
Таблиця 2.3
значення повернене значення опис

0 0x00 Connection Accepted підключення прийнято

0x01 Connection Refused, Брокер не підтримує версію протоколу,

1
unacceptable protocol version використовувану клієнтом

0x02 Connection Refused, Client ID підключається клієнта немає в

2
identifier rejected списку дозволених

0x03 Connection Refused, З'єднання встановлено, але MQTT сервіс

3
Server unavailable не доступний

0x04 Connection Refused, bad

4 Чи не правильний логін або пароль
user name or password

0x05 Connection Refused, not

5 Доступ до підключення заборонений
authorized
 32

значення повернене значення опис

6-255 Зарезервовано

Дані, навантаження
Зміст і формат даних, переданих в MQTT повідомленнях, визначаються в
додатку. Розмір даних може бути обчислений шляхом вирахування з Remaining
Length довжини змінного заголовка.

Розглянемо більш детально процес встановлення з'єднання, посилки і

прийому повідомлень рис. 2.12.

Рис. 2.12. Процес встановлення з'єднання, посилки і прийому повідомлень

1. Встановлення з'єднання починається з передачі від клієнта брокеру

повідомлення CONNECT, в якому зазначаються:
• Client Id - ідентифікатор MQTT-клієнта, унікальне ім'я для кожного пристрою MQTT
підключеного до брокера.
• CleanSession - прапорець видалення збережених повідомлень з попередніх сесій
для даного клієнта;
• Username/Password - ім'я користувача та пароль для ідентифікації та авторизації
клієнта;
• KeepAlive - часовий інтервал, який регулює передачу ping-запитів і ping-відповідей
для контролю відключення однієї зі сторін.
2. Брокер у відповідь посилає клієнту повідомлення CONACK, що
складається з:
• Session Present Flag - вказує чи існують для даного клієнта діючі сесії від
попередніх підключень;
 33

• Connect Аcknowledge Flag - повідомляє клієнту про успішне підключення чи не

підключення.
3. Після того, як клієнт MQTT підключений до брокера, він може публікувати
повідомлення.
4. Публікація відбувається шляхом відправки брокеру від клієнта
повідомлення PUBLISH, де вказуються:
• Topic Name - назва теми, до якої відноситься дане повідомлення. Дане поле є
обов'язковим, так як MQTT-брокер приймає рішення про пересилку того чи іншого
повідомлення клієнту, виходячи з тим, на які клієнт підписаний;
• Спеціальні прапорці - QoS, DUP і RETAIN;
• Корисне навантаження, де передаються самі дані.
1. Після отримання повідомлення PUBLISH брокер відправляє
підтвердження прийому публікації (якщо це задано QoS) і пересилає отримане
повідомлення всім клієнтам, які підписані на дану тему.
2. Щоб отримувати повідомлення з необхідними даними, MQTT-клієнт
повинен підписатися на їх отримання за допомогою повідомлення SUBSCRIBE.
Дане повідомлення складається з двох частин:
• Packet Identifier - необхідно для QoS 1 і QoS 2;
• List of Subscriptions - назви тим, на які клієнт хоче підписатися, і необхідне
значення QoS.
3. У відповідь на повідомлення SUBSCRIBE брокер відправляє клієнту
підтвердження SUBACK, в якому повідомляє про результат підписки (успішна чи ні).
Також клієнт може відписатися від теми, яка більше не представляє для
нього інтересу, відправивши брокеру повідомлення UNSUBSCRIBE, в якому буде
вказана дана тема.
Брокер підтверджує відмову від інформації по цій темі повідомленням
UNSUBACK.

Захист передачі даних

 Для забезпечення безпеки в MQTT протоколі реалізовані наступні
методи захисту:
 Аутентифікація клієнтів. Пакет CONNECT може містити в собі поля
USERNAME і PASSWORD. При реалізації брокера можна використовувати ці поля
для аутентифікації клієнта
 Контроль доступу клієнтів через Client ID
 Підключення до брокера через TLS/SSL.

Структура пакету MQTT або аналіз формату за допомогою Wireshark:

1) CONNECT: MQTT - протокол на основі TCP/IP, тому спочатку було б

встановлення TCP-з'єднання. CONNECT запит Пакет - це перший пакет, який клієнт
надсилає брокеру або серверу після встановлення TCP-з'єднання. Усі три поля
присутні у пакеті запитів CONNECT.
 34

Variable Header Fields (Змінні поля заголовка):

1) Protocol Name Length (Довжина імені протоколу): у цьому полі відображається
довжина імені протоколу. Назва протоколу, довжина - 4.
2) Protocol Name (Назва протоколу): у цьому полі відображається назва
протоколу. Назва протоколу - MQTT.
3) Version(Версія): у цьому полі відображається версія протоколу. Це версія 4.
4) Connect Flag Bits (Підключіть біти прапора): довжина його 8 біт. Кожен біт
детально пояснюється нижче.
User Name Flag(bit 7) (Прапор користувача): Якщо Прапор імені користувача 1,
означає, що ім’я користувача повинно бути присутнім у корисному навантаженні.
Якщо Ім'я користувача прапор - 0, то ім’я користувача не повинно бути присутнім у
корисному навантаженні.
Password Flag(bit 6) (Прапор пароля): Якщо прапор пароля 1 означає, що пароль
повинен бути присутнім у корисному навантаженні. Якщо прапор пароля - 0 означає,
що пароль не повинен бути присутнім у корисному навантаженні. Якщо прапор імені
користувача дорівнює 0, то прапор пароля повинен бути нульовим.
Will Retain(bit 5) (Буде збережено): Якщо прапор Will буде 0, то прапор Will Retain
повинен бути нульовим. Якщо Will Retain буде 0, це означає, що повідомлення не
буде збережене сервером або брокером. Якщо буде збережено 1, повідомлення
буде збережено сервером або брокер.
Will QoS(bit 3 and 4) (Буде QoS): Якщо прапор Will буде 0, то прапор QoS повинен
бути нульовим. Якщо прапор буде позначено 1, то QoS може бути 0 або 1 або 2.
Will Flag(bit 2) (Буде прапор): Якщо Will Flag рівний 1 означає, що Will QoS і Will
Retain в прапорах підключення будуть використовуватись сервером і будуть мати
тему, а повідомлення повинно бути присутнім у корисному навантаженні. Якщо
 35

значення Flag буде 0, значить буде QoS і будуть збережені поля в прапорах
підключення повнинні бути встановлені в 0 і будуть темою, а повідомлення не
повинно бути присутнім у корисному навантаженні.
Clean Session (bit 1) (Очистити сесію): Якщо цей біт 1 означає, що Клієнт і Сервер
повинні відмовитись від попередніх станів сеансу і почати новий сеанс. Якщо цей
біт 0 означає перенесення останніх сеансів, якщо останній сеанс не існує, тоді
розпочніть нове спілкування з нову сесію.
Reserved(bit 0) (Зарезервовано): зарезервовано для подальшої реалізації.
5) Keep Alive (Підтримувати активність): це тривалість, коли підписникик
знаходиться в режимі очікування, значить не отримує дані від брокера, то з'єднання
підтримується шляхом надсилання запиту PING від підписника. Тривалість, після
якої підписник надсилає запит PING брокеру знову і знову, щоб підтримувати
з'єднання, є не що інше, як тривалість підтримки активності. За замовчуванням
Keep Alive - 60 сек .
Payload (Корисне навантаження): навантаження на пакет CONNECT має
ідентифікатор клієнта, довжину ідентифікатора клієнта, тему, повідомлення,
повідомлення користувача, ім’я користувача, пароль. (Payload of CONNECT
packet has Client Identifier , Client Identifier Length , Will Topic , Will Message
, User Name , Password.)
Client Identifier (Client ID): Ідентифікатор клієнта: ідентифікатор клієнта - це
не що інше, як ім’я клієнта, який підключається до сервера чи брокера. Кожен клієнт
повинен мати унікальний ідентифікатор клієнта. Цей ідентифікатор клієнта
допомагає серверу ідентифікувати стани клієнтів.
Client Identifier(Client ID) Length ( Довжина ідентифікатора клієнта (ID
клієнта)): в цьому полі відображається довжина ідентифікатора клієнта.

2) CONNACK: пакет CONNACK надсилається від брокера до клієнта, коли брокер

отримує пакет запиту CONNECT. У пакеті CONNACK присутні лише поля
фіксованого заголовка та змінної заголовка. Корисного навантаження в пакеті
CONNACK немає.

Variable header Fields (Змінні поля заголовка):

 36

Acknowledgement Flags (Підтвердження Прапорів): довжина 8 біт. Кожне поле

детально пояснено нижче.
Reserved (bits 7-1) (Зарезервовано): біти 7-1 зарезервовані для подальшої
реалізації.
Session Present (bit 0) (Сеанс присутній): Якщо сервер приймає з’єднання з
прапором Clean Session = 1 означає, що сервер прийняв новий запит на з'єднання і
у віповідь сервер встановить встановить біт Session Present на 0, означає, що
сервер доступний для прийняття з'єднання і клієнт може підключитися до сервера.
Якщо сервер приймає з'єднання із прапором Clean Session = 0, значення прапора
присутності сесії залежить від того, чи має вже \сервер збереженні стани сеансу чи
ні для цього конкретного ідентифікатора клієнта. Якщо стани вже збережені для
цього конкретного ідентифікатора клієнта, даний сеанс встановлений в 0, якщо ні,
то прапор Session Present встановлений в 1.
Return Code (Код повернення): код повернення відправляється брокером клієнту.
Повернення коду та його значення пояснено в наступній таблиці.

3) PUBLISH: Пакет PUBLISH надсилається Publisher брокером, коли видавець хоче

опублікувати або надіслати дані брокеру.

Variable header Fields (Змінні поля заголовка):

 37

Topic Length (Довжина теми): у цьому полі відображається довжина назви теми.
Topic (Тема): Це поле показує назву теми, щодо якої публікуються дані.

Payload Field( Поле корисного навантаження):

Message Повідомлення: фактичні дані, які публікуються або надсилаються.
4) PUBACK: PUBACK - це підтвердження, яке Брокер надсилає видавцеві лише
тоді, коли видавець опублікує повідомлення з рівнем QOS 1.

5) PUBREC: PUBREC - це підтвердження, яке Брокер надсилає видавцеві лише

тоді, коли видавець опублікує повідомлення з QOS рівня 2.

6) PUBREL: PUBREL надсилається видавцем до брокера, коли видавець отримує

PUBREC від брокера.

7) PUBCOMP: PUBCOMP надсилається Брокером до Видавця лише тоді, коли

брокер отримує PUBREL від видавця.
 38

8) SUBSCRIBE: пакет SUBSCRIBE надсилається підписником до брокера, коли він

к хоче отримати дані від видавця.

Payload (Корисне навантаження):

1) Topic Length (Довжина теми): Тривалість теми, яка підписується.
2) Topic (Тема): Назва теми, яку потрібно підписати.
3) Requested QoS (Запитаний QoS) : QoS підписки.

9) SUBACK: пакет SUBACK - це пакет підтвердження, що надсилається брокером

підписнику, коли підписник отримує пакет запиту SUBSCRIBE.

Payload (Корисне навантаження):

Корисне навантаження пакета підтвердження SUBACK отримане від рівня брокера
рівень QoS.
Зазначене значення QoS = 0 означає рівень QoS 0 Дозволено
 39

Зазначене значення QoS = 1 означає рівень QoS 1 Дозволено

Зазначене значення QoS = 2 означає рівень QoS 2 Дозволено

10) PINGREQ: Пакет запитів PINGREQ надсилається підписником до брокера для

підтримки зв'язку, коли підписник IDLE. Пакет запиту PINGREQ не має змінної
заголовка, а також корисного навантаження.

11) PINGRESP: пакет PINGRESP надсилається брокером підписнику у відповідь на

запит PINGREQ. Пакет PINGRESP не має змінної заголовка, а також корисного
навантаження.

12) DISCONNECT : Це остання відправка пакету від клієнта до брокера, коли клієнт
хоче відключитися. DISCONNECT Пакет запиту не має змінного заголовка, а також
корисного навантаження.
 ШАБЛОНИ ВЗАЄМОДІЇ ДЛЯ ІНТЕРНЕТУ РЕЧЕЙ
Перш ніж почати розробляти новий IoT-проект, варто подумати про те, які
шаблони обміну інформацією найкращим чином для нього підходять.
Насправді, прийняти це рішення слід якомога раніше, ще до того, як обрані
протоколи, способи зв'язку та допоміжна інфраструктура, що розробляється. В основі
цієї рекомендації лежить одна проста причина: не прийнявши таке рішення на самому
початку, розробник, у міру розвитку проекту, ризикує сам себе загнати в кут,
вибратися з якого можна буде лише серйозно переробивши код, архітектуру, модель
безпеки рішення, і то, як воно взаємодіє із зовнішнім світом.
Далі розглянемо одинадцять шаблонів взаємодії в IoT-системах.

ШАБЛОН «ЗАПИТ - ВІДПОВІДЬ»

Шаблон «запит - відповідь» (request - response) - самий широко відомий

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

Шаблон «запит - відповідь»

Саме цей шаблон використовує протокол HTTP . Він же є основою сервісно-
орієнтованих архітектур, веб-служб.

Крім HTTP, шаблон «запит - відповідь» підтримують такі протоколи, як:

 Constrained Application Protocol (CoAP)
 Extensible Messaging and Presence Protocol (XMPP).
Основний недолік даного шаблону, полягає в нерівності учасників обміну
даними, що цілком очевидно проявляється в топології інтернету. Двохнаправлений
обмін даними, коли обидва учасники запитують дані один у одного, може бути
складний в реалізації, особливо якщо на шляху даних є мережеві екрани.
Плануючи використовувати шаблон «запит - відповідь» в проекті, потрібно
вирішити, які частини системи будуть клієнтами, а які - серверами. Якщо, наприклад,
якийсь датчик буде клієнтом, а IoT-шлюз - сервером, датчик сам буде вирішувати,
коли йому передавати на сервер власні покази. Сервер ж, якщо йому знадобляться
дані з датчика, самостійно їх запросити не зможе. Якщо ж датчик зробити сервером,
а шлюз - клієнтом, датчик можна буде опитувати коли завгодно. Однак, тут є одна
проблема: якщо датчик недостатньо захищений, хто завгодно зможе до нього
підключитися. Якщо ж в подібному рішенні задіяна надійна система безпеки, то, як
наслідок, ускладниться спосіб взаємодії клієнта і сервера, та й сама система в цілому.
Можливо, в проект потрібно буде додати додаткові служби, датчики доведеться
оснащувати більш потужним апаратним забезпеченням. Крім того, всім цим буде
складніше управляти.

ШАБЛОН «ПІДПИСКА НА ПОДІЇ»

Цей шаблон (event subscription) дозволяє клієнтові підписуватися на події

заданого типу на сервері. Сервер сповіщає клієнта щоразу, коли відбувається подія,
яка його цікавить. Як результат, відпадає необхідність в постійному опитуванні
сервера.

Шаблон «підписка на події»

Механізм підписки на події може включати в себе вимоги, які залежать від
клієнта, а власне які саме події і при яких умовах його цікавлять.
Переваги використання підписки на події з попереднім розглянутим
шаблоном «запит - відповідь», полягають в тому, що для обміну даними між клієнтом
і сервером потрібно приблизно в два рази менше повідомлень. Крім того, дані
передаються клієнту при виникненні якоїсь події, а не за запитом, що знижує до
мінімуму час між виникненням якоїсь ситуації, що цікавить клієнта, і моментом, коли
він про це дізнається.
Протоколи, які підтримують цей шаблон, включають в себе CoAP, XMPP.
 ШАБЛОН «АСИНХРОННИЙ ОБМІН ПОВІДОМЛЕННЯМИ»

Асинхронний обмін повідомленнями (asynchronous messaging) передбачає

можливість відправки повідомлень між рівноправними системами, що знаходяться на
одному рівні ієрархії. Цей шаблон має на увазі двонаправлений обмін
повідомленнями.

Шаблон «асинхронний обмін повідомленнями»

Серед протоколів, які підтримують даний шаблон, є: XMPP, AMQP,та на
транспортому рівні UDP). Однак, використовуючи UDP для реалізації цього шаблону,
можливі проблеми з мережевими екранами.

ШАБЛОН «НАДІЙНА ДОСТАВКА ПОВІДОМЛЕНЬ»

Додаткам, які виконують критично важливі функції, необхідно знати, що

повідомлення було доставлено одержувачу як мінімум один раз.
Застосування шаблону надійної доставки повідомлень (reliable messaging) дає
гарантію того, що повідомлення буде доставлено одержувачу в точності один раз.
Серед протоколів, що підтримують надійну доставку повідомлень, можна
відзначити (MQTT), AMQP, HTTP і XMPP

ШАБЛОН «БАГАТОАДРЕСНА ПЕРЕДАЧА ПОВІДОМЛЕНЬ»

«Багатоадресна передача повідомлень» (multicasting) використовується коли

одну і ту ж інформацію потрібно відправити декільком одержувачам.
  відправник відсилає одне повідомлення через проміжну ланку системи (брокер
або маршрутизатор),
 далі повідомлення пересилається кільком одержувачам.
 кожен одержувач має зареєструвався для отримання подібних повідомлень.
Завдяки використанню даного шаблону можна знизити навантаження на
мережу, так як відправнику не потрібно самостійно надсилати одне й те саме
повідомлення кожному, хто його чекає.
Використовується:
при синхронізації безлічі пристроїв
при розподілі одних і тих же даних між декількома одержувачами.
Багатоадресну передачу повідомлень підтримують протоколи XMPP, AMQP і UDP.
часто до нього звертаються як до способу обходу обмежень у
використовуваному протоколі, а також - для реалізації на базі якогось протоколу
шаблону «підписка на події».

ШАБЛОН «ВИДАВЕЦЬ - ПІДПИСНИК»

Шаблон «видавець – підписник» (publish - subscribe) є розширенням шаблону

багатоадресної доставки повідомлень. Принципова різниця між ними полягає в тому,
що надіслані повідомлення зберігаються на проміжному вузлі. Ці повідомлення, або
посилання на них, потім розподіляються по зацікавленим в них передплатникам.
Особливості реалізації шаблону залежать:
 від використовуваного протоколу
 від налаштувань підвузлів (які саме повідомлення зберігаються - це
найсвіжіше повідомлення, задана кількість повідомлень, або всі повідомлення.
Шаблон «видавець - передплатник» підтримують MQTT, AMQP, XMPP.
 ШАБЛОН «ЧЕРГА»

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

Черга - абстрактний тип даних з дисципліною доступу до елементів «перший

прийшов - першим вийшов» (FIFO, англ. First in, first out).

Черга зазвичай знаходиться на проміжному вузлі, або в мережі, до якої

підключені всі учасники обміну даними. Черга- це чудовий засіб для балансування
навантаження.
Використовуючи чергу:
 можна уникнути жорсткого зв'язку між системами, які передають дані, і
системами, ці дані отримують і обробляють.
 можна збільшувати або зменшувати кількість приймачів і передавачів
даних.
Серед протоколів, про які вище згадано, лише AMQP володіє вбудованою
підтримкою черг.

ШАБЛОН «БРОКЕРИ ПОВІДОМЛЕНЬ»

Брокери повідомлень (message brokers) є стандартизованими компонентами
допоміжної мережевої інфраструктури IoT-проектів.
Брокер дозволяє пристроям підключатися до нього, займаючись передачею
повідомлень між підключеними до нього клієнтами.
Крім управління повідомленнями, брокери можуть надавати підключеним
клієнтам додаткові служби:
 виступати посередником при реалізації шаблону багатоадресного обміну
повідомленнями
 шаблонів «видавець - підписник»
 «черга».
 надавати службу автентифікації клієнтів.
Протоколи XMPP, AMQP і MQTT, частково задіють цей шаблон.

ШАБЛОН «ФЕДЕРАЦІЯ»

«Федерація» (federation) - це важливий шаблон, в якому певна глобальна

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

федеративна структура є на рівні домену. Кожен домен вказує на власний

набір IP-адрес, і з ним пов'язаний власний веб-сервер.
Домен локальної мережі – це мережа яка об'єднує комп'ютери під одною
загальною політикою безпеки і управляється централізовано.
У систему можна додавати нові веб-сервери, і в нових доменах, не
обмежуючи доступ до існуючих систем. Такий підхід - один з основних ключів до успіху
Всесвітньої павутини.
При використанні протоколів, які передбачають наявність брокерів і
підтримують федерації, брокери з'єднуються між собою для маршрутизації
повідомлень. Кожен брокер управляє автентифікацією у власному домені і знає, як
підключатися до інших доменів для перенаправлення в них повідомлень.
Протоколи: - Simple Mail Transfer Protocol (SMTP), XMPP.
 ШАБЛОН «ВИЯВЛЕННЯ»

Шаблон обміну повідомленнями «виявлення» (discovery) дозволяє створити

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

Шаблон «виявлення»

Клієнти реєструються в реєстрі, а головний пристрій спілкується з ними через

реєстр, використовуючи лише їх заводські ідентифікатори.
Протокол XMPP підтримує цей шаблон.
 4.1 Загальні відомості про радіочастотної ідентифікації RFID
Радіочастотна ідентифікація RFID (Radio Frequency IDentification) -
загальний термін, який використовується для позначення систем, які бездротовим
шляхом за допомогою радіохвиль зчитують ідентифікаційний номер (у формі
унікального серійного номера) будь-якого предмета або людини. RFID відноситься
до великої області технологій автоматичної ідентифікації (Auto-ID), які включають в
себе також штрих-коди, оптичні зчитувачі і деякі біометричні технології, як
наприклад, сканування сітківки ока. У загальному випадку технології Auto-ID
використовуються з метою економії часу і праці, що витрачаються на введення
даних вручну і поліпшення точності інформації. Деякі Auto-ID технології, такі як
системи штрихового коду, часто вимагають участі людини, для сканування і
фіксування інформації вручну. Система RFID побудована таким чином, що дає
можливість вважати і передавати дані в комп'ютерну систему без участі людини і в
реальному масштабі часу. Технологія RFID здатна принести користь в самих різних
областях людської діяльності, включаючи промисловість, торгівлю, освіту,
медицину і ін.

Радіочастотна ідентифікація (RFID) - це технологія безконтактної

автоматичної ідентифікації об'єктів за допомогою радіочастотного каналу зв'язку.
Технологія RFID дозволяє віддалено ідентифікувати об'єкт за допомогою
портативного пристрою (рідера), якщо на об'єкт поміщена спеціальна мітка. У мітці
зберігається інформація про об'єкт. Практично миттєво можна ідентифікувати
велику кількість об'єктів.
Технологія RFID може мати значний вплив на електронну комерцію.
Ідентифікація об'єктів на відстані і зберігання даних про кожного з об'єктів в
електронному вигляді дозволяє глибше інтегрувати процеси, що протікають в
реальному світі, і процеси, властиві тільки електронної комерції.
Розглянемо технологію RFID більш детально.
Отже, будь-яка RFID-система складається з пристрою, що зчитує (рідера) і
невеликих ідентифікуючих пристроїв (RFID-міток), які містять зазвичай резонансний
LC-контур, контролер і постійний запам'ятовувальний пристрій EEPROM (Electrically
Erasable Programmable Read-Only Memory)
(Рис. 4.1). Вміст пам'яті є специфічним для кожної мітки і дозволяє
ідентифікувати носія мітки (людини або об'єкт)

RFID-мітка Зчитувач

EEPROM Генератор

Контролер Демодулятор Декодер

Вміст пам’яті
мітки
 Рис. 4.1 – Основні компоненти системи RFID

Основний принцип роботи такої системи зводиться до наступного. Зчитувач

випромінює радіохвилю, яка приймається єдиною міткою. Мітка, таким чином,
отримує енергію і відображає радіохвилю тієї ж частоти (завдяки індуктивного
зв'язку), модульовану кодованим вмістом пам'яті. Зчитувач приймає цей сигнал,
демодулює і декодує його, щоб визначити вміст пам'яті. Потім ідентифікаційна
система верхнього рівня перевіряє ці дані і, відповідно, управляє процесом.
Привабливість такої системи полягає в тому, що вона забезпечує
безконтактну взаємодію між зчитувачем і RFID-мітками (уникаючи, таким чином,
обмежень на позиціонування об'єкта з міткою), причому мітки не вимагають
джерела живлення.
Однак коли в полі зчитувача знаходяться дві мітки, вони обидві відповідають
на випромінений зчитувачем сигнал. При цьому демодульований сигнал зчитувача
є сумішшю двох компонент від двох міток і не може бути декодований. Така система
не здатна одночасно ідентифікувати два об'єкти. Відомі кілька способів вирішення
цієї проблеми. Деякі з них полягають у тому, що зчитувач і мітки взаємодіють
відповідно до заздалегідь визначених протоколом, так що сигнали кожної мітки
успішно розділяються. Інший підхід полягає у використанні міток на різних частотах.
За дальності зчитування RFID-системи можна поділити на такі типи:
ближньої ідентифікації (зчитування проводиться на відстані до 20 см); ідентифікації
середньої дальності (від 20 см до 5 м); дальньої ідентифікації (від 5 м до 100 м).
Незважаючи на те, що RFID-технологія не нова і її використовують уже
досить довго, про її масове застосування заговорили не так давно. Це сталося через
те, що до недавнього часу RFID-мітки - основний компонент системи - коштували
досить дорого. І тільки деякі компанії могли собі дозволити використання RFID-
мітки, ціна на які до недавнього часу перевищувала долар і більше за одиницю.
Тому, в основному їх використовували компанії, які випускали продукцію
багаторазового використання. В такому випадку код продукту зберігався і його
можна було використовувати в подальшому. Однак найбільш практичні сучасні
RFID-мітки є одноразовими, кінцевий споживач може їх викинути разом з
непотрібною йому упаковкою.
Використання RFID-систем найбільш актуально для компаній, які беруть
участь в процесі виробництва, постачання і реалізації різних товарів. По-перше,
використовуючи RFID-системи, спрощується проведення інвентаризації товарів на
складі. Також значно спрощуються їх прийом і відвантаження. Крім того, завдяки
наявності RFID-міток і RFID-зчитувачів і спеціального комп'ютерного обладнання
стало можливим створювати об'ємні бази даних з обліку і руху товару.
За своїм функціоналом метод збору даних на основі RFID-міток в значній
мірі схожий на технологію штрих-коду, широко застосовується в усьому світі при
маркуванні різних товарів.

4.2 Мітки RFID

Основою технології RFID і головним її компонентом є мітка (англ. Tag) або
транспондер (transmitter - передавач, responder - відповідач), яка містить певну
інформацію (наприклад, про продукт, про виробництво, місцепризначення, термін
реалізації та ін.), передану на зчитувач, коли той проводить опитування мітки.
Більшість RFID міток складається з двох частин (рис. 4.2). Перша - інтегральна
схема для зберігання і обробки інформації, модулювання і демодулювання
радіочастотного сигналу і деяких інших функцій. Друга - антена для прийому і
передачі сигналу. RFID система працює за наступним принципом: радіосигнал
надсилається зчитувачем транспондеру (мітці), який приймає його і відображає
(пасивна мітка) або генерує вихідний сигнал (активна мітка). У процесі зчитування
мітки відбувається передача даних з її пам'яті в комп'ютер, де інформація
обробляється і виводиться в зрозумілому для сприйняття вигляді. Конструктивно
RFID-мітка зазвичай складається з мікрочіпа, прикріпленого до радіоантени.
Компактність RFID-міток залежить від розмірів зовнішніх антен, які за розмірами
перевищують чіп в багато разів і, як правило, визначають габарити міток.

Рис. 4.2 – Схема RFID мітки с індуктивним зв’язком

RFID мітки бувають пасивні та активні (рис. 4.3). Пасивні мітки дешевші і не
мають батареї живлення. У мітці використовується енергія електромагнітних хвиль,
які випромінює зчитувач. Такі мітки застосовуються при відстеженні товарів, при
контролі доступу, промислової автоматизації та електронного стеження за
товарами.

Рис. 4.3 - пасивна (зліва) і активна (праворуч) RFID мітки

Активні RFID мітки мають батарею живлення, яка дозволяє працювати з

більшою точністю і дальністю зчитування. Але через наявність батареї активні мітки
мають обмежений термін служби і вони дорожчі. Найбільш поширений варіант їх
застосування - віддалене спостереження за об'єктами, що мають високу цінність і
вартість. Існують також напівактивні (напівпасивні) мітки, в яких є внутрішнє
джерело живлення (наприклад, батарея) і електроніка для виконання
спеціалізованих завдань. Внутрішнє джерело живлення дає енергію для роботи
мітки. Однак для передачі своїх даних напівактивна мітка використовує енергію, що
випромінюється зчитувачем (рідером). Напівактивна мітка також називається
міткою з допоміжною батареєю. Обмін інформацією між рідером і міткою такого типу
завжди ініціює рідер, а потім починає роботу мітка.
Свого часу індустрія RFID зіткнулася з проблемою «замкнутого кола» - мітки
не стануть дешевше, поки не підвищиться попит на них, а він не підвищиться, поки
вони не стануть дешевше. До недавнього часу відносно висока вартість RFID
обмежувала її використання. В даний час пасивні мітки коштують від 20 центів,
активні мітки - від 10 до 50 доларів і вище.
За конструктивним виконанням виділяють наступні види RFID міток: карти
(пластикові), самоклеючі етикетки паперові та лавсанові, брелки і диски.
Пам'ять мітки - важливий елемент RFID системи. У пам'яті може зберігатися
різна інформація, наприклад, унікальний ідентифікатор об'єкта, місце і дата випуску
продукту і т.д. Зазвичай обсяг пам'яті міток становить від 16 біт до сотень кілобіт.
За типом пам'яті RFID-мітки бувають наступних типів:
1) тільки з читанням RO (Read Only) - дані в них записують тільки один раз,
при їх виготовленні, ці мітки використовуються тільки для ідентифікації об'єкта;
2) з одноразовим записом і багаторазовим читанням WORM (Write Once
Read Many) - ці мітки, крім ідентифікатора містять ще блок пам'яті, в яку можна
одноразово записати інформацію і яку потім можна неодноразово зчитувати;
3) з багаторазовими записом і читанням RW (англ. Read and Write) -
містять блок пам'яті і ідентифікатор, дані в цих мітках можна перезаписувати
неодноразово і відповідно коштують вони дорожче всіх інших міток;
4) мітки SAW-типу, що працюють на принципі поверхневої акустичної хвилі
ПАР (Surface Acoustic Wave - SAW).
Мітка SAW-типу в корені відрізняється від міток на основі мікрочіпів. Для
роботи міток SAW-типу використовуються радіохвилі малої потужності в частотному
діапазоні 2,45 ГГц.
Робоча частота мітки - одна з найважливіших характеристик з'єднання
мітки і зчитувача. Значення використовуваної частоти залежить від додатків і
світових стандартів. Частоти визначають швидкість передачі даних між міткою і
зчитувачем. Чим нижче частота зв'язку, тим менша швидкість. Однак тут також
величезну роль надає довкілля і той об'єкт, на якому розміщується мітка.
У RFID мітки використовується наступні діапазони частот:
1. Низькі частоти (НЧ) LF (Low Frequency) - до 135 кГц. Регулює стандарт
- ISO/IEC 18000-2. Такі мітки краще за інших працюють поблизу рідин і металів,
через що цей стандарт став особливо популярним в області розпізнавання тварин.
НЧ мітки можуть зчитуватися з відстані в кілька сантиметрів і мають найнижчу
швидкість передачі даних. Пасивні мітки даного діапазону мають низькі ціни, однак
в зв'язку з великою довжиною хвилі існують проблеми зі зчитуванням на великі
відстані, а також проблеми, пов'язані з появою колізій при зчитуванні.
2. Висока частота (ВЧ) HF (High Frequency) - 13,56 МГц. Регулює стандарт
- ISO/IEC 18000-3. Мітки 13 МГц дешеві, не мають екологічних та ліцензійних
проблем, добре стандартизовані, мають широку лінійку рішень, в них
використовуються стандартизовані алгоритми шифрування. Широко
застосовуються в таких областях, як карти контролю доступу, платіжні карти,
боротьба з підробкою товарів, відстеження книг і т. д. ВЧ мітки можуть зчитуватися
на відстані до 1м. Як і для діапазону LF, в системах, побудованих в HF-діапазоні,
існують проблеми зі зчитуванням на великі відстані, зчитування в умовах високої
вологості, при наявності металу, а також проблеми, пов'язані з появою колізій при
зчитуванні.
3. Надвисока частота UHF (Ultra High Frequency) - 433 МГц. Регулює
стандарт - ISO/IEC 18000-7. Мітки даної частоти мають найбільшу дальність
реєстрації, в багатьох стандартах даного діапазону присутні антиколізійні
механізми. У UHF RFID-системах в порівнянні з LF і HF нижче вартість міток, при
цьому вище вартість іншого обладнання. Активні мітки (радіомітки з елементами
живлення) забезпечують максимальну дальність зчитування (до 1 км) і надійність
зчитування (100%). Основним мінусом даних систем є вартість міток, на порядок
перевищує вартість пасивних UHF міток.
5. Надвисокі частоти (СВЧ) UHF (Ultra High Frequency) - діапазон 860-930
МГц. Регулює стандарт - ISO/IEC 18000-6. Найпопулярніший діапазон в сучасних
RFID системах. UHF мітки можуть зчитуватися на відстані до 10 метрів, і
забезпечують швидкість передачі даних понад 128 кбіт/сек. Даний стандарт став
основним в таких областях, як логістика та управління ланцюгами поставок, завдяки
зусиллям світових лідерів в цій області (Walmart, Metro Group, Департамент
оборони США та ін.). В даний час частотний діапазон СВЧ відкритий для вільного
використання в Росії в так званому «європейському» діапазоні - 863-868 МГц.
6. Мікрохвильові частоти SHF (Super High Frequency) - 2,45-5,8 ГГц. Регулює
стандарт - ISO/IEC 18000-3. Використовуються в таких областях, як промислова
автоматизація, електронний збір платежів і контроль доступу. Мають діапазон
зчитування, який можна порівняти з UHF (СВЧ), і більш високі швидкості передачі
даних. Позначки, що використовуються є в основному активними або
напівактивними, що обмежує області їх застосування.
Є також СВЧ мітки UHF ближнього поля (Near-Field), які, не будучи
безпосередньо радіомітками, а використовуючи магнітне поле антени, дозволяють
вирішити проблему зчитування в умовах високої вологості, присутності води і
металу. За допомогою даної технології очікується початок масового застосування
RFID-міток в роздрібній торгівлі фармацевтичними товарами (такими, що
потребують контролю достовірності, обліку, але при цьому часто містять воду і
металеві деталі в упаковці) і в інших областях.
У світі в основному використовують HF і UHF частоти
 4.3 Зчитувальні пристрої RFID

Для отримання даних, що зберігаються на RFID-мітках, використовується

пристрій, що зчитує - рідер (англ., Reader). Типовий рідер має одну або кілька антен,
які випромінюють радіохвилі і приймають сигнали від мітки (рис. 4.4). Далі отримана
інформація (ідентифікаційний номер мітки, ID пристрою, що зчитує і час, коли мітка
була прочитана) в цифровому вигляді передається в комп'ютерну систему для
подальшої обробки. Слід враховувати, що зчитувачі повинні працювати на тій
частоті, для якої призначені мітки.
Функції, що виконуються RFID-зчитувачем:
1. Енергопостачання пасивних міток за рахунок передачі енергії міткою з
використанням електромагнітного поля.
2. Читання даних, які зберігаються на мітці.
3. Запис даних на мітку - використовуючи мітки з можливістю читання-
запису, дані можна змінювати, додавати нові і видаляти старі, в будь-який час
протягом усього життєвого циклу продукту.
4. Зв'язок з комп'ютерною системою - зчитувач відповідає за
транспортування інформації між мітками і комп'ютерною системою, це відбувається
за допомогою порту Bluetooth, мережі Ethernet або інших провідних чи бездротових
технологій.

Рис. 4.4 - Структурна схема RFID-зчитувача

Конструктивно зчитувачі бувають ручні, настільні та стаціонарні (рис. 4.5).

Кожен з них використовується в залежності від необхідних потреб. Ручні зчитувачі
застосовуються для пошуку потрібних товарів і застосовуються на складах, в
бібліотеках, в роздрібних магазинах і т.д. Стаціонарні зчитувачі використовуються
як для зчитування, так і для програмування RFID міток. За допомогою них можна
записати, стерти, перезаписати інформацію з мітки. В основному вони
використовується в бібліотеках, на складах.
 а) б) в)
Рис. 4.5 - Зчитувачі (рідери) RFID-міток (зображення не в масштабі): а)
портативний (ручний); б) настільний (RFID-планшет); в) стаціонарний (RFID
ворота)

Мітку і зчитувач з'єднує радіоканал зв'язку для передачі даних, який

організовується з використанням антен. Очевидно, що дальність дії системи RFID
залежить від розмірів антен, наявних у міток і зчитувачів. Антени можуть бути двох
видів: вмонтовані в мітку і корпусовані. У першому випадку антена RFID-мітки
монтується на ту ж поверхню, що і мікрочіп і поміщається з нею в один корпус.
Розміри корпусу мітки зазвичай визначаються розміром і формою антени. Сам
мікрочіп мітки же може бути вкрай малий.
Залежно від потреб додатків підходи до корпусів антен зчитувачів мають свої
відмінності. У переносних пристроях, антена кріпиться на сам зчитувач, в інших,
розміщується на відстані від нього. Тут може бути змонтовано відразу кілька антен
(так звані RFID-ворота, рис. 4.5 В), які розташовані таким чином, що дозволяє
підвищити якість зчитування і дальність сигналів радіохвиль.

4.4 Стандартизація технології RFID

В даний час не існує єдиних міжнародних стандартів в технології RFID. Далі

подано короткий огляд найважливіших з них.
Міжнародна організація по стандартизації ISO (International Organization for
Standardization) спільно з Міжнародним інженерним консорціумом IEC (International
Electrotechnical Commission) розробила серію RFID-стандартів ISO/IEC 18000 для
автоматичної ідентифікації та контролю предметів постачання. Ця серія охоплює
протокол радіоінтерфейсу для систем, що використовуються в системах
постачання, і включає 7 основних радіочастот RFID-технології з усього світу.
ISO розробила також міжнародні стандарти, які регулюють радіочастотну
ідентифікацію тварин, яка зазвичай здійснюється імплантацією транспондера
(мікрочіпа) під шкіру тварини. Так ISO/IEC 11784 визначає, яким чином дані записані
на мітку, а ISO/IEC 11785 встановлює протокол радіоінтерфейсу. Крім цього ISO
створила стандарт протоколу для RFID-міток, що використовуються в платіжних
системах і безконтактних смарт-картах (ISO/IEC 14443) і картах дальньої дії
(ISO/IEC 15693). Організація також встановила стандарти для тестування RFID-
міток і зчитувачів на відповідності технічним вимогам (ISO/IEC 18047) і на вимоги
до проведення випробувань технічних характеристик пристроїв (ISO/IEC 18046).
Центр Auto-ID, який був створений для розробки електронного коду
продукту EPC (Electronic Product Code), запропонував свій власний протокол
радіоінтерфейсу (відмінний від стандарту ISO) для відстеження товарів в
міжнародній логістичній ланці. Спочатку Центр планував створити єдиний
протокол, який би міг зв'язуватися з різними типами (класами) міток. Кожен
наступний тип міток повинен бути більш складним, ніж попередній:
Клас 1: проста, пасивна мітка зворотного розсіювання, доступна тільки для
зчитування, з програмованою довготривалою пам'яттю одноразового
використання.
Клас 2: пасивна мітка зворотного розсіювання з об'ємом пам'яті 65 Кбіт, яку
можна зчитувати і перезаписувати.
Клас 3: напівпасивна мітка зворотного розсіювання з об'ємом пам'яті 65
Кбіт, яку можна зчитувати і перезаписувати; фактично це Клас 2 з вбудованою
батареєю для підтримки розширеної зони дії зчитувачів.
Клас 4: активна мітка з вбудованою батареєю для управління схемою
мікрочіпа і постачання радіопередавача електроенергією, щоб випромінювати
сигнал зчитувача.
Клас 5: активна RFID-мітка, яка може зв'язуватися з іншими мітками Класу
5 і/або іншими пристроями.
Пізніше типи міток змінилися і з часом Центр Auto-ID затвердив також мітки
Класу 0, доступні тільки для читання і програмовані в момент складання. Мітка
Класу 0 використовувала відмінний від Класу 1 протокол, а це означало, що
споживачам доводилося купувати багато протокольних зчитувачів, щоб мати
можливість зчитувати мітки і Класу 1, і Класу 0.
Протоколи Класу 0 і Класу 1 мають пару недоліків, включаючи той факт, що
вони не можуть взаємодіяти один з одним. Одна з проблем полягає в тому, що вони
несумісні зі стандартами ISO. Інша проблема - неможливість застосування
повсюдно. Наприклад, Клас 0 випромінює сигнал на одній частоті і приймає
зворотний вже на інший, але в СВЧ діапазоні, що заборонено в Європі.
З 2003 року після закриття центру Auto ID Labs розробкою стандартів в
області надвисоких частот UHF займається організація EPCglobal Inc., метою якої
є встановлення всесвітніх стандартів для розробки, реалізації та прийняття
електронного коду продукту EPC і створення мережі EPCglobal. Специфікація
EPCglobal, націлена на операції в мережах збуту, є найбільш глобальної
специфікацією для RFID і застосовується в дуже широкому наборі прикладних
систем. Існує два покоління стандартів EPC. Перше покоління визначало тільки
мітки класу 0 і класу 1. Мітки класу 0 програмувались під час виготовлення «R/O».
В мітки класу 1 інформація могла бути записана тільки один раз користувачем, при
створенні мітки для конкретного додатка «WORM». Клас 0 і клас 1 мають різні
протоколи для роботи зі зчитувачем.
 Існують модифікації класів, які підтримуються «відкритими» стандартами
EPC Global. Найбільш широко використовуються модифікації це клас 0 g1, який
відрізняється розміром пам'яті (96 біт замість прийнятих спочатку 64 біта) і клас 1b
(С1bg2), де всього 128 біт, 96 біт з яких (EPC-код) доступні для багаторазового
перезапису.
Для усунення проблем, що виникають при роботі з мітками першого
покоління, в 2004 році EPC Global введений стандарт другого покоління для
транспондерів, що працюють в області ультрависоких частот, іменований EPC
Generation 2 - загальний протокол обміну даними для всіх продуктів другого
покоління. Протокол розроблений для міток Класу 1 gen2, але повинен підходити
для роботи з розробляються в перспективі класами (планується створення міток
класу 2, 3, 4 і 5).

4.5. Робота мітки на основі протоколу EM4100

Більшість міток є пасивними: вони не містять власних джерел живлення і
тільки передають ідентифікатор у відповідь на запит.
Звичайні мітки використовують протокол EM4100, EM-Marin - формат
безконтактних радіочастотних ідентифікаційних карт компанії EM Microelectronic-
Marin, одні з найпоширеніших в Україні. Відносяться до класу пасивних RFID карт,
оскільки не мають вбудованого джерела живлення. Працюють в частотному
діапазоні 125 кГц і зберігають унікальний номер довжиною 40 біт.
Випускаються в різноманітних конструктивах (найбільш поширені Clamshell-
карти, ISO 7810 -карти, брелки).
Ідентифікаційні картки ISO/IEC 7810 - Фізичні характеристики - це
міжнародний стандарт, який визначає фізичні характеристики ідентифікаційних
карт. ISO-карти можуть випускатися додатково з магнітною смугою,
ідентифікаційним номером, виготовленим методом тиснення, полем для підпису
власника картки. Персоналізація ISO-карт відбувається за допомогою
термодруку,шовкографії, офсетного друку. Персоналізація Clamshell-карт
проводиться за допомогою наклейок, на які наноситься вся необхідна інформація.
Велика кількість EM4100-сумісних міток використовує одну і ту ж мікросхему-
транспондер, що існують в декількох конфігураціях, які відрізняються протоколами
кодування і швидкістю передачі даних.
Транспондер звичайної мітки має наступні характеристики:
 Несуча частота: 125 кГц, 13,56 МГц, 433 МГц, зазвичай з амплітудною
модуляцією
 Кодування: манчестерський код
 Швидкість передачі: 1, 2, 4 кбіт/с
 Вшитий ідентифікатор, який не перезаписується, опціонально -
жорсткий диск
 Підрахунок контрольних сум за допомогою парності і CRC
Транспондери RFID (мітки) є пристроями, що несуть цифрову інформацію,
яку можна зчитувати з відстані за допомогою зчитувача RFID (Reader). Для того,
щоб мати можливість читати інформацію, що зберігається на мітках RFID, зчитувач
повинен знати, як зберігається інформація та протокол який використовується.
Один з найбільш поширених є протокол EM4100, названий так тому, що мікрочіп в
центрі мітки базується на контрольній мікросхемі фірми EM Microelectronic.
Для пасивної мітки (транспондер EM4100) зчитувач генерує магнітне поле
частотою 125 кГц. Потрапляючи в магнітне поле зчитувача, мітка отримує енергію і
починає циклічно модулювати магнітне поле зчитувача сигналом, в якому
зашифрований її ідентифікаційний код, а це 64 біти даних.

Читання RFID транспондера EM4100

 Патерн синхронізації (позначають початок даних): дев'ять одиниць.
 Ідентифікатор виробника/версія: 2 блоки по 5 біт з яких 4 біта- дані, а
п'ятий – парність.
 Унікальний ідентифікатор: 8 блоків (32 біти даних) по 5 біт, з яких 4 біта
- дані, а п'ятий – парність (кожен блок супроводжується 32 бітами даних D16-
D39
 Контрольна сума: 4 біта парності, підраховані за стовпцями
 Стоп-біт: «0»

Розглянемо, як прочитати трансподер по протоколу EM4100.

Трансподери, які сумісні з EM4100, мають пакет даних має довжину 80 біт -
64 біт даних і 16 біт контрольної суми CRC 16 CCITT. Інформаціюможна читати з
трансподера, але ніякі дані не можуть бути змінені, або нові дані, записані на карту,
після того, як картка була запрограмована з початковими даними. Формат даних
наведений на рис.4.6.

Рис.4.6. Формат даних пакета трансподера

Приведемо приклад рядка для трансподера, що містить дані $ 2С (номер версії) та

$ 007755А2 як рядок даних.
Прочитаємо код RFID транспондера за протоколом EM4100.
Дев'ять одиниць, потім передається код, який розбивається по п'ять біт,
перші чотири біти переводяться в шістнадцяткове число, п'ятий-це контрольна
сума попередніх чотирьох. Так йдуть десять груп «п’ятірок», потім передається
побітова контрольна сума всіх шістнадцяткових чисел. Далі йде нульовий стоп-біт.
 Таблиця 4.1. Приклад розбиття переданого коду

Рис. 4.7. Формат даних пакета трансподера, містить дані $ 2С (номер версії) та $
007755А2 як рядок даних.

Приклад 2. Трансподер містить дані $ 06 (номер версії) та $ 001259E3 як рядок

даних.

Формат даних пакета трансподера буде мати вигляд:

Контрольні питання

1. Яке призначення системи радіоідентіфікаціі RFID?

2. Які елементи входять до складу RFID-системи?
3. Як влаштована RFID-мітка? Які мітки бувають?
4. У чому особливість RFID-міток, які працюють на принципі поверхневої
акустичної хвилі?
6. Які частотні діапазони використовуються в RFID-мітках?
7. Поясніть функції зчитувальних пристроїв RFID-систем.
8. Який стан стандартизації технології RFID?
9. Які проблеми заважають більш масового впровадження технології RFID?
 6.1. Стандарти бездротового персональної локальної
мережі

Датчики та інші пристрої, підключені до інтернету, потребуються

в способі передачі і отримання інформації. Це тема персональної
мережі регіону (PAN) і ближнього зв'язку. В екосистемі інтернету речей
зв'язок з датчиком або виконавчим механізмом може здійснюватися по
мідних проводах або по бездротових персональних мережах регіону
(WPAN). У цьому розділі ми концентруємося на WPAN, оскільки це
найпоширеніший метод промислового, комерційного та споживчого
підключення до речей в інтернеті. Зв'язок на основі проводів і раніше
використовувався, але, перш за все, в успадкованих галузях і областях,
які не є сприятливими для радіосигналів. Існує безліч різних каналів
зв'язку між кінцевою точкою і інтернетом; деякі можуть бути побудовані
на традиційному стеку IP (6LoWPAN), а інші використовують не-IP
(інтернет-протокол) для максимізації економії енергії (BLE). IP-системи
зв'язку потребують додаткової деталізації, а з не-IP не обов'язково.
Системи зв'язку, відмінні від IP, оптимізовані для економії витрат і
енергії, тоді як рішення на базі IP зазвичай мають менше обмежень
(наприклад, 802.11 Wi-Fi).

6.2. Стандарти 802.15

IEEE 802.15 - це робоча група IEEE, що входить до комітету

стандарту IEEE 802. Група займається визначенням стандарту
бездротових персональних мереж (WPAN). Включає в себе сім
цільових груп.
Спочатку група 802.15 була створена таким чином, щоб
зосередитися на переносних пристроях (еквівалент персональної
мережі). Згодом робота групи 802.15 значно розширилася і тепер
фокусується на більш високих протоколах, а саме швидкості передачі
даних, діапазонах вимірювань до кілометрів і спеціальних комунікаціях.
Велика кількість пристроїв щодня впроваджуються з використанням
протоколу 802.15.x.
Нижче наведено список різних протоколів, стандартів і
специфікацій, які IEEE підтримує і регулює:
IEEE 802.15 - визначення бездротової локальної мережі;
IEEE 802.15.1 - WPAN/Bluetooth. Оригінальна основа Bluetooth PAN.
Перша група сфокусована на Bluetooth-технології. Вона визначає
фізичний рівень (PHY) і рівень управління доступом до середовища
(MAC) для бездротового з'єднання стаціонарних і портативних
пристроїв в межах особистого або робочого простору. Стандарти були
прийняті в 2002 і 2005 роках.
IEEE 802.15.2 - Вирішення конфліктів. Специфікації співіснування
для WPAN і WLAN для Bluetooth. Друга група визначає співіснування
бездротових персональних мереж (WPAN) з іншими бездротовими
пристроями, що працюють на неліцензійних частотних діапазонах,
таких, як бездротові локальні мережі (WLAN). Стандарт IEEE 802.15.2-
2003 був опублікований в 2003 році, після чого діяльність цільової групи
2 було припинено.
IEEE 802.15.3 - Високошвидкісні WPAN. Висока швидкість передачі
даних (55 Мбіт/с і більше) в WPAN для мультимедіа:
 802.15.3a - високошвидкісні поліпшення PHY;
 802.15.3b - високошвидкісні удосконалення MAC;
 802.15.3c - високошвидкісна ( до 3 Гбіт/с). передача з
використанням технології mm-wave (міліметрова хвиля);
IEEE 802.15.4 – Низькошвидкісні WPAN. Низька швидкість передачі
даних в сукупності з дуже тривалим часом автономної роботи батареї
(місяці і навіть роки) і простотою пристроїв. Стандарт визначає як
фізичний (рівень 1), так і канальний (рівень 2) рівні моделі OSI.
З 2003 року почали створюватись цільові групи для перегляду
стандарту 802.15.4, робота яких і вилилась у наступні стандарти
(поправки):
IEEE 802.15.4a (формально називається IEEE 802.15.4a-2007) -
це поправка до стандарту IEEE 802.15.4, яка визначає додаткові
фізичні рівні. Поправка представляє принциповий інтерес у зв'язку із
забезпеченням більшої точності (від 1 метра), більшою пропускною
спроможністю мережі, масштабованість швидкості передачі даних,
більшої дальності і більш низьким енергоспоживанням і вартості.
IEEE 802.15.4b - поправка була прийнята в червні 2006 р і
опублікована у вересні 2006 як IEEE 802.15.4-2006. Цільова група
802.15.4b була зібрана для створення поліпшень і пояснень до
стандарту IEEE 802.15.4-2003, таких, як зменшення числа
неоднозначностей, позбавлення від непотрібних складнощів,
підвищення гнучкості використання ключів безпеки, розширення
діапазону частот і ін.
IEEE 802.15.4c поправка була схвалена в 2008 р і опублікована
в січні 2009 р Вона визначає нові специфікації радіочастотного спектру
в зв'язку з відкриттям китайськими регулюючими органами 314-316
МГц, 430-434 МГц і 779-787 МГц частотних діапазонів для використання
WPAN на території Китаю.
IEEE 802.15.4d - поправка була створена для внесення змін до
802.15.4-2006 стандарту. Поправка визначає новий фізичний рівень і
деякі зміни в MAC-підрівні, необхідні для підтримки нового діапазону
частот (950 МГц - 956 МГц) в Японії.
IEEE 802.15.4e - поправка була створена для внесення поправок
в MAC-підрівень стандарту 802.15.4-2006. Мета цієї поправки полягає
в тому, щоб розширити функціональність MAC стандарту 802.15.4-2006
для а) забезпечення більшої підтримки промислових ринків, б)
забезпечення сумісності зі змінами, що відбулися з китайськими WPAN.
Також були додані технології channel hopping і variable time slot, сумісні
з ISA100.11a. Дані зміни прийняті в 2011 році.
IEEE 802.15.4f - поправка була створена для визначення нових
бездротових фізичних рівнів і поліпшення MAC-підрівня стандарту
802.15.4-2006 для забезпечення підтримки активних RFID - систем,
двононапрямлених і навігаційних додатків.
IEEE 802.15.4g - поправка створена для корегування фізичного
рівня стандарту 802.15.4. Поправка розроблена для забезпечення
підтримки сільномаcштабованих, географічно рознесених мереж з
мінімальною інфраструктурою і мільйонами кінцевих вузлів, таких, як
[розумні мережі електропостачання]. Стандарт 802.15.4g був
прийнятий в квітні 2012 року.
IEEE 802.15.5 - Mesh мережі (змішані).
IEEE 802.15.5 надає архітектурний каркас, що дозволяє будувати
на основі WPAN-пристроїв сумісні, стабільні і масштабовані бездротові
Mesh-мережі. Стандарт складається з двох частин: низькошвидкісні і
високошвидкісні WPAN Mesh-мережі. Низькошвидкісні Mesh-мережі
будуються на IEEE 802.15.4-2006 MAC, тоді як високошвидкісні - на
IEEE 802.15.3/3b MAC. В обох типах мереж підтримуються такі опції, як
ініціалізація мережі, адресація і багатострибкове поширення. Крім того,
низькошвидкісна Mesh-мережа підтримує групову адресацію,
забезпечення надійності мовлення, трасування маршруту і функції
економії енергії, а високошвидкісна Mesh-мережа підтримує multihop-
обслуговування реального часу.
IEEE 802.15.6 мережева інфраструктура для медицини та розваг.
У грудні 2011 року була створена цільова група IEEE 802.15.6 для
розробки стандарту мереж датчиків моніторингу показників тіла людини
(Body Area Network, BAN), також забезпечує роботу різних медичних,
побутових або розважальних програм.
IEEE 802.15.7 видимий світловий зв'язок з використанням
структурованого освітлення.
У грудні 2011 року цільова група для розробки стандарту IEEE
802.15.7 завершила визначення фізичного і MAC-рівнів для зв'язку з
видимого світла (англ. Visible Light Communication, VLC). Протягом
січня 2009 року проводились засідання групи, на яких обговорювалося
написання стандарту атмосферної оптичної лінії зв'язку (англ. Free-
space optical communication ), що використовує VLC.
IEEE 802.15.8 - без доступу до мережі зі швидкістю від 10 Кбіт /
с до 55 Мбіт/с.
IEEE 802.15.9 - протокол управління ключами (KMP), стандарт
управління для забезпечення безпеки.

6.3. Технологія Bluetooth

Bluetooth - це технологія бездротового зв'язку з низьким
енергоспоживанням.
Bluetooth - це вже давно всім відома бездротова технологія, яка
використовується сьогодні мало не у всіх електронних пристроях.
Протокол Bluetooth працює на частоті 2,4 ГГц у тому ж
неліцензованому діапазоні частот ISM, де також технології, такі як
ZigBee та WiFi.
Bluetooth - виробнича специфікація бездротових
технологя персональних мереж (Wireless personal area network, WPAN).
Bluetooth забезпечує обмін файлами і інформацією між різноманітними
приладами, як персональні комп'ютери, мобільні телефони, принтери,
цифрові фотоапарати, та інші різноманітні гаджети і на надійній,
безкоштовній, повсюдно доступній радіочастоті для ближнього зв'язку.
Bluetooth дозволяє цим пристроям повідомляти, коли вони знаходяться
один від одного в радіусі близько 10 м в старих версіях протоколу і до
400 м починаючи з версії Bluetooth 5. Дальність сильно залежить від
перешкод.
Майже щороку з'являються все більш модернізовані версії цієї
технології, її розвиток не стоїть на місці. Незважаючи на це, з попитом,
що збільшується на пристрої в основі яких лежить IoT, користувач
бажає отримати більш нові і розширені функції Bluetooth, тому у цій темі
буде детально розглянута технологія Bluetooth з особливим акцентом
на нову специфікацію Bluetooth 5.0.
Специфікація Bluetooth була розроблена групою Bluetooth Special
Interest Group (Bluetooth SIG); перша версія (1.0) появилась в 1998 році
з метою замінити плутанину кабелів і шнурів, що з'єднують комп'ютерну
периферію з радіочастотним середовищем. На даний момент вона
вважається морально застарілою, і ні в одному пристрої, наявному в
продажу, не використовується.

Версії Bluetooth .
Bluetooth 1.0 (1998) . Перші версії Bluetooth мали погану сумісність між
продуктами різних виробників. У 1.0 і 1.0B була обов'язковою передача
адреси пристрою (BD_ADDR) на етапі встановлення зв'язку, що робило
неможливою реалізацію анонімності з'єднання на протокольному рівні і
було основним недоліком даної специфікації.
Bluetooth 2.0 + EDR (2004)- швидкість передачі даних 2,1 Мбіт / с, до
теперішнього часу використовується в недорогих гарнітурах. Enhanced
data rate (EDR) - це технологія, що дозволяє збільшити
швидкість передачі даних через Bluetooth
Bluetooth 2.1 і Bluetooth 2.1 + EDR - теж, що і в першому випадку плюс
підтримка NFC і зменшено до 10 разів енергоспоживання. Near Field
Communication (NFC) — технологія бездротового високочастотного
зв'язку малого радіусу дії «в один дотик». Ця технологія дає можливість
обміну даними між пристроями, насамперед смартфонами та
безконтактними платіжними терміналами, що перебувають на відстані
близько 10 см. Швидкість обміну даними становить до 424 кбіт/с.
Bluetooth 3.0 + HS - значно збільшена швидкість передачі даних до 24
Мбіт/с, але зросло енергоспоживання, популярності ця технологія не
здобула і в аудіо пристроях зустрічається дуже рідко. HS, або High
Speed технологія передачі інформації з високою швидкістю,
забезпечує швидкість до 24 Мбіт/сек.
Bluetooth 4.0 + BLE (2009) - зменшено енергоспоживання зі
збереженням швидкості 24 Мбіт/с - зустрічається у відносно дорогих
моделях навушників, дозволяє зберегти якість звуку на високому рівні.
Bluetooth Low Energy, Bluetooth LE, BLE, представлена також як
Bluetooth Smart, технологія з низьким енергоспоживанням.
Bluetooth 4.1 – у цій версії з'явився захист від перехресних завад при
спільній роботі з LTE-модулями, установленими у всіх 4G смартфонах;
Bluetooth 4.2 (2014) - збільшення швидкості і поліпшений захист
передачі даних, зустрічається у відносно дорогих моделях навушників і
аудіо плеєрах, Важливо, що версія 4.2 через профіль протоколу
підтримки Інтернет-протоколу дозволяє Bluetooth-інтелектуальним
датчикам отримати доступ до Інтернету безпосередньо через
підключення 6LoWPAN. Це IP-з'єднання дає змогу використовувати
існуючу інфраструктуру IP для керування пристроями Bluetooth Smart
"edge".
 Стандарт: специфікація основної технології Bluetooth 4.2
 Частота: 2,4 ГГц (ISM)
 Діапазон: 50-150м (Smart/BLE)
 Обмін даними: 1 Мбіт/с (розумний/BLE)
 віддаль до 60 метрів.

Популярність версії протоколу Bluetooth 4, а також деякі його

обмеження стали причинами для створення наступної специфікації
Bluetooth 5.
Розробники ставили перед собою цілий ряд цілей: розширення
радіусу дії, зростання пропускної здатності при розсилці широкомовних
пакетів, поліпшення завадозахищеності і так далі.
Bluetooth 5.0 (2016) - в порівнянні з попередньою версією
збільшений радіус дії в 4 рази, швидкість збільшена в 2 рази (поступово
з'являється у флагманських смартфонах з 2017 року).
 Стандарт: специфікація основної технології Bluetooth 4.2
 Частота: 2,4 ГГц (ISM)
 Діапазон: 50-150м (Smart/BLE)
 Обмін даними: 2 Мбіт/с (розумний/BLE)
 віддаль до 240 метрів
 функція Dual Audio (одночасне відтворення звуку на двох
підключених пристроях, наприклад можна підключити 2 пари
навушників)
В Bluetooth стіни і інші перешкоди послабить сигнал, як і Wi-Fi.

Структура пакета Bluetooth

Кожен пристрій Bluetooth має унікальний 48-бітовий адрес
(BD_ADDR) - це унікальний 48-розрядний ідентифікатор, призначений
виробником кожного пристрою Bluetooth.
Адреса Bluetooth зазвичай відображається у вигляді 6 байтів,
записаних у шістнадцятковій формі та розділених двокрапками
(приклад - 00: 11: 22: 33: FF: EE).
Верхня половина Bluetooth-адреси (найбільш значущі 24 біти)
називається організаційно унікальним ідентифікатором (OUI), також
відомий як ідентифікатор компанії. З його допомогою можна визначити
виробника пристрою (MAC-адрес Bluetooth ). Префікси OUI
присвоюються Інститутом інженерів електротехніки та електроніки
(IEEE).
 Крім ідентифікації, адреса пристрою Bluetooth використовується
для визначення структури частоти стрибків у радіозв'язку між
пристроями Bluetooth.
Адреса Bluetooth складається з трьох частин: NAP, UAP та LAP.

NAP
Незначна частина адреси (2 байти). Містить перші 16 біт OUI. Значення
NAP використовується в кадрах частотної стрибкової синхронізації.
UAP
Частина верхньої адреси (1 байт). Містить решту 8 біт OUI. Значення
UAP використовується для просування в різні алгоритми специфікації
Bluetooth.
LAP
Частина нижньої адреси (3 байти). Цю частину Bluetooth-адреси
виділяє постачальник пристрою. Значення LAP однозначно ідентифікує
пристрій Bluetooth як частину коду доступу у кожному переданому кадрі.
LAP і UAP складають значну адресу (SAP) адреси Bluetooth.

Процес зв'язку Bluetooth

Режим Bluetooth орієнтований на з'єднання.
У Bluetooth WPAN реалізується кілька подій Bluetooth:
реклама - ініціюється пристроєм для трансляції на пристрої
сканування, щоб попередити про наявність пристрою, який бажає або
передавати, або просто передати повідомлення в рекламному пакеті;
підключення - процес створення пари між пристроєм і хостом;
періодична реклама (для Bluetooth 5) - дозволяє рекламному пристрою
періодично рекламувати 37 первинних каналів шляхом перескакування
каналів (метод FHSS) з інтервалом від 7,5 до 81,91875 с. FHSS - метод
розширення спектра зі стрибкоподібною перебудовою частоти ( англ.
Frequency Hopping Spread Spectrum, FHSS ). Відповідно до алгоритму
FHSS, в Bluetooth несуча частота сигналу стрибкоподібно
змінюється 1600 разів в секунду (перепригуючи з однієї частоти на
іншу), є 79 виділених робочих частот шириною в 1 МГц. Послідовність
перемикання між частотами для кожного з'єднання є псевдовипадковою
і відома тільки передавачу і приймачу, які кожні 625 мкс (один
тимчасовий слот) синхронно перебудовуються з однієї несучої частоти
на іншу. Таким чином, якщо поруч працюють кілька пар приймач-
передавач, то вони не заважають один одному. Цей алгоритм є також
складовою частиною системи захисту конфіденційності інформації, що
передається: перехід відбувається по псевдовипадковому алгоритму і
визначається окремо для кожного з'єднання.
При передачі цифрових даних і аудіосигналу (64 кбіт/с в обох
напрямках) використовуються різні схеми кодування: аудіосигнал не
повторюється (як правило), а цифрові дані в разі втрати пакета
інформації будуть передані повторно.
Розширена реклама (для Bluetooth 5) - дозволяє використовувати
розширені PDU (блок даних) для підтримки ланцюжка реклами і
великих PDU.
Отже, перш ніж будь-яке з'єднання Bluetooth з'явиться, пристрій
має бути виявлено, щоб він відповідав на сканування фізичного каналу
і згодом відповідав адресою свого пристрою і іншими параметрами.
Пристрій повинен знаходитися в режимі підключення для
контролю сканування даних.
Процес підключення виконується в три етапи:
1) запит - на цьому етапі два пристрої Bluetooth ніяк не
асоційовані або не пов'язані; вони нічого не знають один про одного.
Пристрої повинні виявити один одного через запит. Якщо інший
пристрій слухає, він може відповісти своєю адресою BR_ADDR;
2) пейджинг - це утворення з'єднання між двома пристроями.
Кожен пристрій знає BD_ADDR один від одного в цей момент;
3) підключено - існує чотири підрежими стану підключення. Це
нормальний стан, коли два пристрої активно спілкуються:
a) активний режим - це нормальний режим роботи для передачі і
прийому даних Bluetooth або очікування наступного слота передачі;
б) режим аналізу - режим енергозбереження. Пристрій, по суті,
спить, але буде прослуховувати передачі під час певних слотів, які
можуть бути змінені програмно (наприклад, 50 мс);
в) режим очікування - це тимчасовий режим низького
споживання енергії, ініційований провідним або веденим пристроєм.
Пристрій не буде слухати передачі, як в режимі аналізу, і ведений
тимчасово ігнорує ACL-пакети. В цьому режимі перемикання на
підключене стан відбувається дуже швидко;
г) режим парковки - як зазначено раніше, цей режим застарів в
Bluetooth 5.
Якщо цей процес завершиться успішно, два пристрої можуть
бути примусово автоматично підключені, коли вони знаходяться в зоні
дії. Тепер пристрої сполучаються. Одноразовий процес сполучення
найбільш поширений в підключенні смартфонів до стереосистеми
автомобіля, але він може застосовуватися в будь-якому місці і в IoT.
Парні пристрої будуть використовувати ключ, який використовується в
процесі автентифікації.

mesh-мереж Bluetooth
Після того, як була випущена специфікація Bluetooth 5, SIG
зосередились на формалізації mesh-мережі Bluetooth. Bluetooth SIG
опублікував профіль mesh-мережі, пристрій і специфікацію моделі 1.0
13 липня 2017 г. Це відбулось через шість місяців після випуску
специфікації Bluetooth 5.0. До офіційної специфікації Bluetooth 5 у
Bluetooth SIG існували власні і спеціальні схеми, які використовують
старіші версії Bluetooth для створення mesh-середовищ.
Три специфікації, опубліковані Bluetooth SIG, такі:
специфікація профілю Mesh 1.0 - визначає основні вимоги, що
дозволяють інтегроване рішення mesh-мережі;
специфікація моделі Mesh 1.0 - базова функціональність вузлів
в mesh-мережі;
властивості пристрою Mesh 1.0 - визначає властивості
пристрою, необхідні для специфікації моделі mesh-мережі. Поки
невідомо, чи існує який-небудь межа розміру mesh-мережі. У
специфікації є деякі обмеження. За специфікації 1.0 може бути до 32
767 вузлів в mesh-мережі Bluetooth і 16384 фізичних групах.
Максимальний час життя, яке вказує на глибину mesh-мережі,
становить 127.
 Топологія mesh-мережі Bluetooth

Mesh-мережа Bluetooth використовує концепцію мережі повеней.

У мережі повені кожен вхідний пакет, отриманий вузлом в сітці,
відправляється через кожен вихідний зв'язок, за винятком посилання на
батька повідомлення. Перевага повеней полягає в тому, що, якщо пакет
може бути доставлений, він буде доставлений (хоча, ймовірно, багато
разів через багато маршрутів). Він автоматично знайде найкоротший
маршрут (який може змінюватися за якістю сигналу і відстані в
динамічної mesh-мережі). Алгоритм є найпростішим у реалізації
протоколів маршрутизації.

Крім того, він не вимагає центрального менеджера, такого як

мережа Wi-Fi, заснованого на центральному маршрутизаторі. Для
порівняння, альтернативні типи маршрутизації mesh-мережі включають
в себе алгоритми на основі дерева. За допомогою алгоритмів дерева
(або алгоритмів кластерного дерева) координатор необхідний для
створення екземпляра мережі і стає батьківським вузлом. Однак дерева
не обов'язково є істинними mesh-мережами. Інші протоколи
маршрутизації mesh-мереж включають проактивну маршрутизацію, яка
підтримує сучасні таблиці маршрутизації на кожному вузлі і реактивну
маршрутизацію, яка тільки оновлює таблиці маршрутизації на кожному
вузлі на вимогу; наприклад, коли дані повинні відправлятися через
вузол. Zigbee (розглянутий пізніше) представляє собою форму
проактивної маршрутизації, звану Ad Hoc On-Demand Distance Vector
(AODV).

Рис. 6.1. ілюструє потокове мовлення. Час прибуття на кожному

рівні може динамічно змінюватися від вузла до вузла. Крім того, mesh
мережа повинна бути стійкою для дублювання повідомлень, що
надходять на будь-який вузол, як у випадку вузла 7 і вузла П.
 Рис. 6.1 Архітектура повені в mesh-мережі. Д = Джерело, О=
Одержувач. Джерело виробляє дані, які поширюються і протікають
через кожен вузол в сітці

Основним недоліком мережі повеней є пропускна здатність, а

саме перевантаження в mesh-мережі Bluetooth.
Основні компоненти mesh-мережі Bluetooth
вузли - це пристрої Bluetooth, які були попередньо підготовлені
і є членами mesh-мережі;
непідготовлені пристрої - це пристрої, які можуть
приєднатися до mesh-мережі, які ще не є її частиною і не були
підготовлені;
елементи - вузол з декількома складовими частинами. Кожна
частина може контролюватися і адресуватися незалежно. Прикладом
може служити вузол Bluetooth з датчиками температури, вологості і
люмен. Це буде єдиний вузол (датчик) з трьома елементами;
шлюз mesh-мережі - вузол, який може переводити сполучення
між mesh-мережею і технології не-Bluetooth.
Після підготовки вузол може підтримувати необов'язковий набір
функцій, які включають:
реле - вузол, що підтримує реле, називається вузлом
ретрансляції і може повторно передавати отримані повідомлення;
проксі - дозволяє пристроям Bluetooth LE, які не підтримують
meshсеті Bluetooth спочатку, взаємодіяти з вузлами в mesh-мережі. Це
виконується з використанням проксі-вузла. Проксі-сервер надає
інтерфейс GATT із застарілим пристроєм Bluetooth, і визначається
проксі-протокол, заснований на каналі, орієнтованому на з'єднання.
Успадковане пристрій зчитує і записує протокол проксі-сервера GATT,
а проксі-вузол перетворює повідомлення в справжні PDU mesh-мережі;
мала потужність - деякі вузли в mesh-мережі повинні мати
надзвичайно низькі рівні енергоспоживання. Вони можуть
обслуговувати інформацію про екологічні датчиках (наприклад,
температуру) один раз на годину і налаштовуватися за допомогою
керуючого вузла або хмари один раз на рік. Цей тип пристрою не може
бути поміщений в режим прослуховування, коли повідомлення буде
надходити тільки один раз в рік. Вузол входить в роль, звану вузлом
низької потужності (LPN), який з'єднує його з дружнім вузлом. LPN
переходить в стан глибокого сну і опитування пов'язаного одного для
будь-яких повідомлень, які могли з'явитися під час сну;
друг - дружній вузол пов'язаний з LPN, але не обов'язково
обмежується потужністю, як LPN. Друг може використовувати виділену
ланцюг або силу стіни. Обов'язок одного полягає в тому, щоб зберігати
і буферизувати повідомлення, призначені для LPN, до тих пір, поки LPN
не прокидається і не опитає його для повідомлень. Багато повідомлень
можуть бути збережені, і один передасть в певному порядку,
використовуючи прапор додаткових даних (MD). Рис. 6.2. ілюструє
топологію мережі Bluetooth з різними компонентами, оскільки вони
будуть пов'язані один з одним в реальному mesh-мережі. Mesh-мережа
Bluetooth буде кешувати повідомлення на кожному вузлі; це має
вирішальне значення в мережі повеней. Оскільки одне й те саме
повідомлення може надійти кількома з різних джерел, кеш забезпечує
пошук останніх повідомлень, отриманих і оброблених. Якщо нове
повідомлення ідентично одному в кеші, тоді воно відкидається. Це
забезпечує ідемпотентність системи.
Рис. 6.2. Топологія мережі Bluetooth
 6.4. ZigBee
ZigBee — стандарт для набору високорівневих протоколів
зв'язку, що використовують невеликі, малопотужні цифрові приймачі,
заснований на стандарті IEEE 802.15.4-2006 для бездротових
персональних мереж (наприклад, бездротові навушники, що з'єднані з
мобільними телефонами за допомогою радіохвиль короткохвильового
діапазону). Технологія визначається специфікацією ZigBee, яка
розроблена з метою бути простішою та дешевшою, ніж інші персональні
мережі, такі як Bluetooth. Основними областями застосування ZigBee є
бездротові сенсорні мережі, автоматизація житла ( «Розумний будинок»
і «Інтелектуальна будівля»), медичне обладнання, системи
промислового моніторингу та управління, а також побутова електроніка
і «периферія» персональних комп'ютерів.
Сама назва Zigbee походить від двох слів: «zigzag» («зигзаг») і
«bee», що в перекладі означає «бджола». Таким чином,
словосполучення «танець бджоли» відмінно відображає суть пористої
структури даного каналу зв'язку.
Відносини між IEEE 802.15.4 і ZigBee подібні до таких, що є між
IEEE 802.11 і альянсом Wi-Fi. Специфікація ZigBee 1.0 була
ратифікована 14 грудня 2004 і доступна для членів альянсу ZigBee.
Про перший профіль програми — «Домашня автоматизація»
ZigBee, було оголошено 2 листопада 2007. ZigBee працює в
промислових, наукових та медичних неліцензійних радіодіапазонах:
868 МГц в Європі, 915 МГц у США і Австралії, та 2.4 ГГц в більшості
країн світу. Через більш низької частоти ZigBee має кращу здатність
проникати крізь стіни і перешкоди в порівнянні з традиційними
сигналами 2,4 ГГц. Zigbee не використовує всі специфікації PHY і MAC
IEEE 802.15.4.
Як правило, виробники чипів ZigBee, поєднують радіо- й
мікроконтролер з розміром Flash-пам'яті від 60К до 128К. Радіомодуль
також можна використовувати окремо з будь-яким процесором та
мікроконтролером. Як правило, виробники радіомодулів пропонують
також набір програмного забезпечення ZigBee, хоча доступні й інші
незалежні стеки.
Альянс ZigBee — є органом, який забезпечує і публікує стандарти
ZigBee, він також публікує профілі додатків, що дозволяє виробникам
пристроїв створювати сумісні продукти. Поточний список профілів
додатків, опублікованих, або вже знаходяться в роботі:
 Zigbee є приватним і закритим стандартом. Це вимагає
ліцензійного збору та угоди, наданого Альянсом Zigbee. Ліцензування
надає сертифікат відповідності Zigbee і логотип. Це гарантує сумісність
з іншими пристроями Zigbee.
Мережі ZigBee будуються з базових станцій трьох основних
типів:
Координатор ZigBee (ZC) — головний пристрій, що
запускає мережу та керує нею, виконує функції центру управління
мережею і може виступати центром довіри (trust-центр) - встановлює
політику безпеки, задає топологію мережі, здійснює налаштування в
процесі приєднання пристроїв до мережі, зберігає ключі безпеки. Це
найбільш дорогий тип пристроїв (обов'язково пристрій з повною
функціональністю FFD), так як він повинен містити всю інформацію про
мережеві з'єднання, мати великий обсяг пам'яті і високу продуктивність.
У кожній мережі має бути хоча б один координатор ZigBee, який
повинен запустити мережу на початку.
Маршрутизатор Zigbee (ZR) - цей компонент є
необов'язковим, але може виступати як проміжний маршрутизатор, а
саме: транслює пакети, здійснює динамічну маршрутизацію, відновлює
маршрути при перевантаженнях в мережі або відмові будь-якого
пристрою. При формуванні мережі маршрутизатори приєднуються до
координатора або до інших маршрутизаторів, а також можуть
приєднувати дочірні пристрої - маршрутизатори і кінцеві пристрої.
Маршрутизатор може обслуговувати до 32 сплячих пристроїв.
Кінцевий пристрій ZigBee (ZED) — зазвичай це простий
термінал, наприклад, вимикач світла або термостат, що обмінюється
інформацією з вузлом вищого рівня (координатором або з
маршрутизатором), тобто він може приймати і відправляти пакети, але
не займається їх трансляцією і маршрутизацією. Така
функціональність дозволяє вузлу перебувати в сплячому стані левову
частину часу, що дозволяє економити енергоресурс батарей. ZED
потребує мінімальної кількості пам'яті.
Принцип роботи мережі. Запуск всієї мережі проходить за
допомогою координатора. Далі маршрутизатор розсилає пакети і
відновлює маршрути після перевантажень, утворюючи безперебійну
роботу всієї мережі. Приймає і відправляє пакети кінцевий пристрій, але
маршрутизацією займатися не може. Розширення мережі відбувається
через підключення до маршрутизатора кінцевих пристроїв та інших
маршрутизаторів. Первинне приєднання до мережі для всіх пристроїв
при формуванні здійснює тільки пристрій-координатор. Після
формування цю функцію може виконувати і маршрутизатор.
Розглянемо процес передачі даних від координатора до
пристрою рис. Коли пристрій збирається передати дані координатору
в мережі з маячками, він спочатку намагається виявити маячок. Коли
маячок знайдений, пристрій підлаштовується до структури фрейма.
Пристрій передає дані координатору, використовуючи слотовий
механізм CSMA/CA. У відповідь координатор відсилає фрейм
повідомлення про отримання. На цьому цикл обміну закінчується.
Якщо пристрій збирається передати дані в мережі без маячків, він
передає дані, використовуючи безслотовий метод CSMA/CA.

Рис. 6.3. Процес передачі даних від координатора до пристрою

Коли координатор бажає передати динячі пристрою в мережі з
маячками, він поміщає в маячок інформацію про те, що є дані, готові
до передачі (рис. 6.3). Пристрій періодично аналізує вміст маячка і,
якщо в ньому є інформація про наявність повідомлення, готового до
передачі, пристрій передає команду запиту даних, використовуючи
слотовий метод CSMA / CA. Координатор підтверджує прийом запиту
даних за допомогою фрейму повідомлення. Слідом за цим
координатор відсилає дані, використовуючи слотовий метод доступу
CSMA / CA. Пристрій підтверджує прийом даних відправкою
повідомлення.
Якщо координатор збирається передати дані без використання маячка,
він запам'ятовує дані і чекає запиту від пристрою. Пристрій може
передати команду запиту даних координатору, використовуючи
бесслотовий метод CSMA / CA. Координатор спочатку посилає
повідомлення про отримання (в тому ж циклі обміну), потім,
використовуючи CSMA / CA, відсилає дані та отримує повідомлення
про отримання від пристрою.
Zigbee підтримує три основні топології (рис. 6.4):
зіркова мережа - один ZC з одним або декількома ZED. Тільки
розширює зв'язок між двома вузлами і тому обмежена на відстані вузла.
Також потрібна надійна зв'язок з єдиною точкою відмови в ZC; У
мережах зірка мережні пристрої «слухають» ефір і «говорять» в ефір у
моменти часу, «прив'язані» до сигналів маяків. В інший час пристрої
«сплять».

Рис. 6. 4. Топології мереж Zigbee від простішої зіркової мережі і

кластерне дерево - мережа з декількома переходами, яка

використовує маяк і розширює охоплення мережі і діапазон по мережі
зірок. Вузли ZC і ZR можуть мати дочірні елементи, але ZED
залишаються істинними кінцевими точками. Вузли-нащадки
взаємодіють тільки зі своїм батьком (наприклад, з невеликою мережею
зірок). Батьки можуть спілкуватися вниз за течією зі своїми дітьми або
вгору по потоку до свого батька. Все ще існує проблема в єдиній точці
відмови в центрі;
mesh-мережа - динамічне формування шляху і зміна форми.
Маршрутизація може відбуватися з будь-якого початкового пристрою на
будь-який пристрій. Використовує алгоритми маршрутизації дерева і
таблиці. Радіостанції ZC і ZR повинні постійно бути опитані, щоб
виконувати вимоги до маршрутизації, забираючи для цього час
автономної роботи. Крім того, обчислення затримки в mesh-мережі
може бути важким, якщо не недетермінованим. Деякі правила
ослаблені; проте маршрутизатори в певному радіусі один від одного
можуть безпосередньо зв'язуватися один з одним. Основною перевагою
є те, що мережа може вирости за межі видимості і мати кілька
додаткових шляхів.

Zigbee використовує дві унікальних адреси для кожного вузла:

Довга адреса (64 біт) - призначається виробником пристрою і є
незмінна. Унікально відрізняє пристрій Zigbee від всіх інших пристроїв
Zigbee. Це те ж саме, що і 64-розрядна адреса 802.15.4 (приклад - 00:
11: 22: 33: FF: EE)
Верхні 24 біти є унікальним ідентифікатором організації, а нижні
40 біт розподіляються пристроям. Адреси поставляються блоками і
можуть бути замовлені в IEEE.
коротка адреса (16 біт) - не є обов'язковою і використовується в
кадрах частотної стрибкової синхронізації.
В ZigBee передбачено три режими передачі даних:
 передача від пристрою до мережевого координатора;
 передача від мережевого координатора до пристрою;
 передача між двома одноранговими пристроями.
У зірковій топології використовуються тільки два перші варіанти,
оскільки в ній не існує обмінів між одноранговими пристроями.
Стандарт IEEE 802.15.4 визначає тільки фізичні і канальні рівні
моделі OSI, але нічого вище. Крім того, в 802.15.4 нічого не говориться
про багатоходової зв'язки або про прикладні програми. Саме тут
входить у гру Zigbee (і інші стандарти, засновані на 802.15.4). Zigbee є
приватним і закритим стандартом. Це вимагає ліцензійного збору та
угоди, наданого Альянсом Zigbee. Ліцензування надає сертифікат
відповідності Zigbee і логотип. Це гарантує сумісність з іншими
пристроями Zigbee.
Архітектура стека ZigBee складається з набору блоків, рис.6.5
званих рівнями (layers). Кожен рівень надає певні служби для більш
високого рівня. Архітектура стека ZigBee, базується на стандартній
семирівневій моделі Open Systems Interconnection (OSI), але визначає
тільки рівні з необхідною функціональністю.
Стандарт IEEE визначає два нижніх рівні: фізичний рівень (PHY)
і підрівень контролю доступу до середовища (MAC). В свою чергу
ZigBee Alliance, ґрунтуючись на цьому базисі визначає додатково
мережевий рівень (NWK) і рівень додатків (APL).

Номер
OSI модель Мережа Функції
рівня
APL (APS, ZDO Передача повідомлень,
7 Прикладний и Application пошук пристроїв,
Objects) ZigBee визначення ролі пристроїв
6 - -
Представлення
5 Сеансовий - -
4 Транспортний - -
3 Мережевий NWK ZigBee Безпека, маршрутизацїя
LLC IEEE
802.15.4
Канальний
SSCS IEEE CSMA/CA, передача
2 (передачі
802.15.4 маячків, синхронізація
даних)
MAC IEEE
802.15.4
PHY IEEE Радіоканал
1 Фізичний
802.15.4 868 МГц, 915 МГц ,2,4 ГГц
Рис. 6. 5. Архітектура стека ZigBee

Основні характеристики технології ZigBee визначені в стандарті

IEEE 802.15.4 на Фізичному і канальному рівняхі:
 швидкість передачі: 250 кбіт/с;
 коротку 16-бітову адресу або розширену довжиною 64-біти;
 виділення інтервалу часу для передачі інформації кожним вузлом;
 метод доступу до каналу типу CSMA /CA;
 протокол обміну з повідомленням про отримання;
 мале споживання потужності;
  контроль рівня енергії;
 наявність індикатора якості зв'язку;
 16 каналів в діапазоні 2,45 ГГц

Рівні стека техногогії ZigBee

Фізичний рівень PHY (Physical layer) забезпечує інтерфейс між
стеком протоколів і середовищем передачі інформації (ефіром), а саме
описує низькорівневий механізм керування радіочастотним
приймачем/передавачем.
Функції: прийом і передача даних через радіоканал, оцінка якості
зв'язку, здійснення вибору каналу та вимірювання потужності
радіосигналу,
ZigBee може працювати в трьох частотних діапазонах. 868 МГц,
915 МГц ,2,4 ГГц .
Канальний рівень DLL (Data link layer) рівень передачі даних,
що складається з трьох підрівнів: MAC, SSCS і LLC, які визначаються
стандартом IEEE 802.15.4
Підрівень MAC керує доступом до радіоканалу, використовуючи
метод CSMA/CA, а також також відповідає:
 за передачу фреймів: маячкових, даних, повідомлення про
отримання; команд MAC-підрівня
 синхронізацію
 забезпечення надійних методів передачі інформації.
Підрівень SSCS (Service Specific Convergence Sublayer -
"підрівень зближення специфічних сервісів") виконує роль інтерфейсу
між підрівнями LLC і MAC.
Підрівень LLC виконує зв'язок мережевого рівня з рівнем MAC.
Функції: управління доступом до середовища передачі;
забезпечення пересилання кадрів між будь-якими двома пристроями
бездротової мережі.
Мережевий рівень NWK (Network Layer) використовує методи,
що забезпечують:
 реєстрацію в мережі нового пристрою і виключення його з
мережі;
 -забезпечення безпеки при передачі фреймів;
 вказівку маршруту фрейму до місця призначення;
 прокладку маршрутів між пристроями в мережі;
 виявлення в мережі найближчих сусідів;
 запам'ятовування необхідної інформації про сусідніх вузлах.
 На мережевому рівні, окремо виділяється рівень NWK
координатора, який відповідає за організацію нової мережі, коли це
потрібно і призначення адрес нових пристроїв, що підключаються до
мережі.
Рівень додатків APL (Application Laye) пов'язує стек протоколів
з кінцевим додатком користувача і складається з підрівнів: підтримки
додатків APS, об'єктів пристроїв ZigBee ZDO, об'єктів додатків АО.
Підрівень підтримки додатків APS (Aрplication Support sub-layer)
забезпечує інтерфейс між мережевим рівнем і рівнем додатків APL за
допомогою загального набору сервісів:
 Підрівень підтримки додатків APS, які використовуються як
підрівнем об'єктів пристроїв ZDO, так і прикладними об'єктами
Application Objects, обумовленими користувачем.
Підрівень підрівень об'єктів пристроїв ZigBee ZDO (ZigBee
Device Object) який забезпечує:
 -визначення ролі пристроїв в мережі (координатор,
маршрутизатор або термінал);
 - ініціювання або відповідь на запит з'єднання;
 - захист інформації;
 - виявлення пристроїв в мережі і визначення, який сервіс
вони надають.
Підрівень об'єктів додатків АО (Application Objects), визначенні
суто виробником.
Структура фреймів
Структура фреймів була спроектована за критерієм мінімальної
складності, що забезпечує надійну передачу даних в зашумленому
каналі. Відповідно до моделі OSI, кожен нижче розташований рівень
додає до протоколу свій заголовок.
Стандарт передбачає чотири типи фреймів:
 фрейм маячка;
 фрейм даних;
 фрейм повідомлення про отримання;
 фрейм команд MAC-підрівня
 Формат фрейму даних за стандартом IEEE 802.15.4
*
Фрейм даних починається з преамбули, яка спільно з полем "Старт"
служить для синхронізації даних в приймачі, поле "Довжина" містить
довжину поля MAC-підрівня в 8-бітових байтах (октетах). Поле
"Керування" містить службову інформацію про керування кадрами,
поле "Номер" містить порядковий номер даних, поле "Адреса" містить
адресну інформацію, в тому числі 16-бітний короткий або 64-бітний
розширений адрес. Поле дані і завершується фрейм полем контрольної
суми КС.

Безпека Zigbee Zigbee будує правила безпеки відповідно до IEEE

802.15.4.
Zigbee надає три механізми безпеки:
 списки управління доступом (ACL)
 128-бітове шифрування AES
 таймери свіжості повідомлень.

Головні переваги мереж ZigBee перед багатьма іншими

бездротовими локальними і персональними полягають в
наступних параметрах:
 Здатність до самоорганізації та самовідтворення
 Mesh-мережі, завдяки цій топології, дані передаються навіть при появі
перешкод у вигляді розриву з'єднання;
 знижене споживання енергії, наявність режиму сну;
 криптографічний захист всіх даних, які передаються;
 автоматична організація нових пристроїв;
 автоматичний вибір найбільш кращого алгоритму маршрутизації;
ТЕМА 6. СИСТЕМИ І ПРОТОКОЛИ ДАЛЬНЬОГО ЗВ'ЯЗКУ
6.1 Технологія LPWAN
6.2. Архітектура LoRaWAN мереж
6.3. SigFox
6.4.NB- IoT

6.1 Технологія LPWAN

Розвиток Інтернету речей (IoT, Internet of Things) істотно змінив
природу підключених пристроїв, створивши величезні можливості для
сімейства технологій глобальних мереж з низьким енергоспоживанням.
Для передачі даних на великій відстані необхідно звертатися до
глобальної обчислювальної мережі. В даній темі охоплюються основні
пристрої і топології глобальної мережі, включаючи стільниковий (4G і
5G) та інші пропрієтарні системи зв'язку, такі як LoRa і Sighfox.
Розглянемо стільникові і телекомунікаційні системи з точки зору даних.
Дальня передача даних - це зазвичай послуга, що отримується
при підписці на постачальника, який має в своєму розпорядженні вишку
стільникового зв'язку чи шлюзи і надає вдосконалену інфраструктуру.
LPWAN (англ. Low-power Wide-area Network - «енергоефективна
мережа далекого радіусу дії») - бездротова технологія передачі
невеликих за обсягом даних на дальні відстані, розроблена для
розподілених мереж телеметрії, міжмашинної взаємодії і Інтернету
речей. LPWAN є однією з бездротових технологій, що забезпечує збір
даних з різноманітного устаткування (датчиків, лічильників та сенсорів),
які можуть знаходитись у різних фізичних середовищах.
LPWAN можуть вміщувати розміри пакетів від 10 до 1000 байт зі
швидкістю передачі даних до 200 Кбіт/с. Радіус дії LPWAN коливається
від 2 км до 10000 км, залежно від технології.
Технологія LPWAN орієнтована на програми, що вимагають
гарантованої передачі невеликого обсягу даних, можливості тривалої
роботи мережевих пристроїв від автономних джерел живлення,
великого територіального охоплення бездротовою мережею.
Будь-які існуючі бездротові технології передачі даних (рис. 6.1)
володіють такими характеристиками як дальність, швидкість і
енергоефективність. Причому одночасно можна відповідати лише 2-м
з 3-х.
 Рис. 6.1 Відповісь бездротових технологій 2-м з 3-х
характеристик

Технологія LPWAN забезпечує енергоефективну передачу даних

на великі відстані, та підтримує пристрої, здатні передавати інформацію
на десятки кілометрів і при цьому працювати протягом декількох років
на одній батареї.
Технологія LPWAN дозволяє легко створити таку мережу, в якій
одна базова станція збирає дані в радіусі до 10 кілометрів в міських
умовах з сотень тисяч різнотипних автономних датчиків і при цьому
залишається дешевше і надійніше традиційних рішень.
В основі принципу передачі даних за технологією LPWAN на
фізичному рівні PHY лежить властивість радіосистем - збільшення
енергетики, а значить і дальності зв'язку при зменшенні швидкості
передачі. Чим нижче бітова швидкість передачі, тим більше енергії
вкладається в кожен біт і тим легше виділити його на тлі шумів в
приймальні частини системи. Таким чином, низька швидкість передачі
даних дозволяє домогтися більшої дальності їх прийому.
Підхід, який використовується для побудови LPWAN-мережі рис.
6.2., схожий з принципом роботи мереж мобільного зв'язку. LPWAN-
мережа використовує топологію «зірка», де кожен пристрій взаємодіє з
базовою станцією безпосередньо. Мережі міського або регіонального
масштабу будуються з використанням конфігурації «зірка із зірок».
Пристрій або модем з LPWAN-модулем передає дані по
радіоканалу на базову станцію. Станція приймає сигнали від всіх
пристроїв в радіусі своєї дії, оцифровує і передає на віддалений сервер,
використовуючи доступний канал зв'язку: Ethernet, стільниковий зв'язок,
VSAT.
Отримані на сервері дані використовуються для відображення,
аналізу, побудови звітів та прийняття рішень і надаються в зручному для
користувача вигляді. Зворотний канал зв'язку дозволяє управляти
пристроями віддалено та оновлювати програмне забезпечення.
Для передачі даних по радіоканалу, як правило, застосовується
неліцензований спектр частот, дозволений до вільного використання в
регіоні побудови мережі: 2,4 ГГц, 868/915 МГц, 433 МГц, 169 МГц.

Рис. 6.2.,
Характеристики Порівняння LPWAN з іншими бездротовими
технологіями (рис. 6.3)
 Рис.6.3. Порівняння технології LPWAN з іншими бездротовими
технологіями

Переваги LPWAN:
Велика дальність передачі сигналу у порівнянні з іншими
бездротовими технологіями використовуваними для телеметрії GPRS
або ZigBee, досягає 10-15 км.
Низький рівень споживання енергії у кінцевих пристроїв, завдяки
мінімальним витратам енергії на передачу невеликого пакета даних.
Висока проникаюча здатність радіосигналу в міській забудові при
використанні частот суб-гігагерцового діапазону.
Висока масштабованість мережі на великих територіях.
Відсутність необхідності отримання частотного дозволу та плати
за радіочастотний спектр, при використанні неліцензованих частот (ISM
band).
Недоліки LPWAN:
Відносно низька пропускна здатність, внаслідок використання
низької частоти радіо каналу. Варіюється в залежності від
використовуваної технології передачі даних на фізичному рівні,
становить від кількох сотень біт/с до декількох десятків кбіт/с.
Затримка передачі даних від датчика до кінцевого додатка,
пов'язана з часом передачі сигналу, може досягати від декількох секунд
до декількох десятків секунд.
Відсутність єдиного стандарту, який визначає фізичний рівень і
управління доступом до середовища для бездротових LPWAN-мереж.

Основними областями застосування технології LPWAN є

бездротові сенсорні мережі, автоматизація збору показників приладів
обліку, системи промислового моніторингу та управління.
Енергетика: системи бездротового автоматизованого контролю
та обліку електроенергії.
Житлово-комунальне господарство: віддалений збір показників
приладів обліку: води, тепла, газу, електрики.
Сільське господарство: контроль вологості і температури
ґрунтів, моніторинг освітленості і рівня сонячної радіації, моніторинг
стану складів та овочесховищ.
Безпека і охоронні системи: резервування каналів зв'язку,
контроль проникнення, контроль затоплення приміщень, контроль
пожежної безпеки.
Системи міського менеджменту та «розумне місто»: управління
освітленням, моніторинг автомобільного трафіку, контроль зайнятості
паркувальних місць, контроль температури, шуму, вологості,
освітленості, забруднення повітря і інш.
Моніторинг навколишнього середовища: контроль якості повітря
і води, контроль рівня води в річках і озерах, моніторинг пожежної
небезпеки в лісах.
Будівництво: контроль обладнання, моніторинг параметрів
конструкцій і будівель.
Медицина: пристрої що носяться. Автотранспорт: контроль
швидкісного режиму і стилю водіння.
Виробництво і системи постачання: контроль параметрів
обладнання, моніторинг стану вантажів. Додатки Інтернету речей.
Мережі LPWAN
LPWAN - це не одна технологія, а група різноманітних мережевих
технологій малої потужності, що приймають багато форм. LPWAN
можуть використовувати ліцензовані або неліцензовані частоти і
включати власні або відкриті стандартні опції.
Є два основні варіанти реалізації LPWAN мережі:
 мережі з ліцензуванням робочих частот (підвищена
потужність, відносно висока швидкість, немає перешкод)
 мережі, що працюють в Безліцензійному діапазоні частот
(низька потужність, низька швидкість, обмеження робочого циклу
передавача, можливі перешкоди від інших гравців)

Розглядають на сьогодні три основні технології для побудови

LPWAN мереж, що конкурують за великомасштабне розгортання
IoT:
 NB- IoT - еволюція стільникового зв'язку;
 SigFox в світі і Стриж в Росії - UNB безліцензійний
LPWAN;
 LoRa - широкосмуговий безліцензійний LPWAN.
Активно почали розвивати мережі LPWAN і в Україні, а саме
оператори стільникового зв'язку Київстар, і Vodafone -мережу NB-IoT, а
оператор lifecell - LoRa .
NB-IoT швидше за все захопить більшу частину
високоприбуткового ринку, але безліцензійні технології можуть
захопити більше низькодохідних ринків з мільярдами підключених
простих і дешевих пристроїв.
Характеристики LPWAN
Характеристика Порядок Значення
Спектр Неліцензфйний 868 МГц для LoRa, Sigfox,
(LoRaWAN, SIGFOX, Weightless та 2.4 ГГц для
Weightless, Ingenu), Ingenu. Ліцензійні частоти
ліцензійний починаючи для LTE-M/CAT-M1,
з 3GPP (eMTC, NBIoT, NBIoT, EC-GSM
EC-GSM)
Радіус Великий ~10 км
Кількість Багато Тисячі
об'єктів
Обсяг даних Невеликий Десятки кбіт в день
Швидкість Низька Десятки кб/c
передачі даних
Затримка Від маленької до До кілька хвилин
великої
Робота від Тривала До 20 років
батареї
Вартість модуля Низька <$5

6.2. Архітектура LoRaWAN мереж

Протокол LoRaWAN

Вперше мережевий протокол LoRaWAN (Long Range Wide Area

Networks) було презентовано на ринку бездротових технологій в 2015
році Semtech Corporation і дослідницький центр IBM Research
представили новий відкритий мережевий протокол, при цьому високо
оцінивши його конкурентоспроможність в порівнянні з Wi-Fi і
стільниковими мережами. Також був відзначений ряд переваг
LoRaWAN - це, в першу чергу, можливість розгортання міжмашинних
(M2M) комунікацій на віддалях до 20 км. і швидкостях до 50 Кбіт/с. При
цьому витрати електроенергії мінімальні, що дозволяє досягати
максимального часу автономної роботи (кілька років) на одному
акумуляторі типу АА.
Особливості нової технології дозволяють вибирати сферу
застосування LoRa пристроїв практично без обмежень: домашня
автоматизація та Інтернет речей (Internet of Things, IoT), промисловість
і розумні міста, енергетика та охорона здоров'я, і багато, багато іншого.
Саме поява технології LoRaWAN викликала великий резонанс на
ринку бездротового зв'язку, що спричинило за собою необхідність
прийняти єдиний стандарт для глобальних мереж з низьким
енергоспоживанням - LPWAN (з англ. Low Power Wide Area
Network). Власне, абревіатура LoRa об'єднує в собі метод модуляції
LoRa в бездротових мережах LPWAN, розроблений Semtech, і відкритий
протокол LoRaWAN.
Для підтримки, розвитку та стандартизації нової технології була
створена некомерційна організація LoRa Alliance, її засновниками стали
найбільші відомі виробники електроніки (IBM, Semtech, Cisco, Kerlink,
IMST і ін.) І провідні телекомунікаційні оператори (Bouygues Telecom,
KPN, SingTel, Proximus, Swisscom). Впровадження стандарту дозволить
зробити завдання об'єднання мільйонів пристроїв в Інтернет речей
максимально простою і зрозумілою, а також вирішить проблему
надання послуг Інтернету Речей організаціям і фізичним особам через
операторів зв'язку.
Коли говорять про технологію LoRaWAN, то найчастіше мають на
увазі і метод модуляції LoRa, розроблений Semtech, і відкритий
протокол LoRaWAN.
LoRaWAN - це протокол зв'язку і системна архітектура для мережі, що
безпосередньо впливають на термін служби батареї, пропускну
здатність мережі, якість обслуговування, безпеку і різноманітність
програм, що обслуговуються мережею.
LoRaWAN призначений для бездротового підключення «речей», до
регіональних, національних або глобальних мереж і орієнтований на
основні вимоги до Інтернету, такі як:
 двонаправлений зв'язок
 наскрізна безпека
 мобільність
 послуги локалізації
LoRa - це фізичний рівень радіозв'язку, що забезпечує
безпосередньо передачу даних.
LoRa - технологія, яка використовує метод Chirp Spread Spectrum
(лінійно-частотна модуляція), що кодує дані в імпульси. Подібний спосіб
передачі даних протягом десятиліть використовувався у військовому і
космічному зв'язку».
Діапазон поширення радіохвиль в LoRaWAN залежить від
багатьох факторів:
 можливостей базових станцій
 пристроїв
 завад.
У вересні 2017 року куля-зонд, який піднявся на висоту 38 км,
обладнаний підключеним радіомодулем LoRa, антеною і GPS-
модулем, зміг відправити дані на віддаль в 702 км.

Якщо модуляція LoRa є, фізичним рівнем (OSI media layer 1), що

забезпечує безпосередньо передачу даних, то LoRaWAN (Long Range
Wide-Area Networks) - це MAC протокол канального рівня (OSI media
layer 2) для мереж з великою кількістю вузлів з великим радіусом дії і
низьким власним споживанням потужності.

Архітектура мережі LoRaWAN.

Мережа LoRaWAN має просту архітектуру типу "зірка" (від англ.
Star) без ретрансляторів і mesh-зв'язків.
 Для вузлів мережі характерні:
 низьке енергоспоживання (до 10 років роботи від звичайних
батарей АА)
 невисока швидкість обміну даними, велика дальність зв'язку
(15 км в сільській місцевості і 5км в щільній міській забудові)
 низька вартість кінцевого обладнання.
Протокол LoRaWAN оптимізований для кінцевих пристроїв, що
працюють від батарей і включає в себе різні класи вузлів, забезпечуючи
компроміс між швидкістю доставки інформації і часом роботи пристроїв
при використанні живлення від батарей (акумуляторів). Протокол
забезпечує повний двосторонній зв'язок, а архітектура, за допомогою
спеціальних методів шифрування, забезпечує загальну надійність і
безпеку всієї системи. Архітектура LoRaWAN розроблялася з
урахуванням можливості активної роботи з мобільними кінцевими
пристроями (endnode), що є одним з швидко зростаючих напрямків
«Інтернету речей».
Типова архітектура складається з ключових елементів:
 кінцеві вузли
 шлюзи
 мережевий сервер
 сервер додатків.
Кінцевий вузол (End Node) - його основні функції - управління і
вимірювання. Він складається з послідовності керуючих елементів і
датчиків вимірювання.
Шлюз LoRa (Gateway / Concentrator) - пристрій, який приймає
дані через радіоканал від кінцевих пристроїв і передає їх в транзитну
мережу. Прикладами таких мереж можуть виступати Ethernet, WiFi,
стільникові мережі та будь-які інші телекомунікаційні канали. Сам шлюз
і його кінцеві пристрої утворюють мережеву топологію типу зірка. Такий
тип конструкції складається з багатоканальних пристроїв прийому і
передачі, що дозволяють обробляти сигнали, одночасно надходять по
декількох каналах або кілька сигналів, отриманих від одного
каналу. Таким чином, кілька аналогічних пристроїв забезпечує зону
покриття мережі та прозору двосторонню передачу даних між кінцевими
вузлами і сервером.
Мережевий сервер (Network Server) - центр управління для
управління мережею. З його допомогою встановлюється розклад,
регулюються швидкості, відбувається аналіз, обробка та зберігання
отриманих даних.
Сервер додатків (Application Server) - пристрій для збору даних
з кінцевих вузлів і віддаленого контролю їх роботи.
Принцип роботи мережі LoRaWAN
Мережа LoRaWAN складається з множини кінцевих пристроїв
(модулів LoRa), які по бездротових з'єднаннях передають дані на один
шлюз LoRa (Gateway/Concentrator), або одночасно на декілька. Шлюз і
кінцеві пристрої утворюють мережеву топологію типу «зірка». Зв'язок
між шлюзами здійснюється через бездротові рішення, які
використовують широкосмугову модуляцію LoRa.
Далі, шлюзи передають зашифровані дані, отримані від кінцевих
пристроїв (end-node) на центральний хмарний сервер (Network Server)
мережі провайдера підключеного за допомогою стандартних
технологій Wi-Fi/Ethernet/3G/4G, що відносяться до рівня інтерфейсів
IP-мереж (фізичний і канальний рівніи OSI) і далі надходять на сервер
додатків (App Server) сервіс-провайдера.
На сервері додатків ( може бути автономнний Web-сайт або в
«хмарі») отримані з кінцевих пристроїв дані зберігаються,
відображаються й обробляються. Для аналізу IoT-даних можуть
застосовуватися методи Big Data. Користувачі за допомогою
клієнтських додатків, встановлених на смартфон або ПК, мають
можливість доступу до інформації на сервері додатків.
 Рис. 6.4. Архітектура мережі LoRaWAN
Як цілісна конструкція, мережа LoRaWAN є топологію типу зірка,
вона має кінцеві вузли, які, за допомогою шлюзів, утворюють прозорі
мости і повідомляються з центральним сервером мережі. Така
архітектура має на увазі, що центральний сервер і шлюзи підконтрольні
і належать до оператора мобільного зв'язку, а кінцеві вузли -
абонентам. Абоненти при такій схемі отримують прозорий, безпечний,
двонаправлений спосіб обміну інформацією.
Оскільки LoRaWAN утворюють глобальну мережу, головною
турботою розробників стала максимальна захищеність і
конфіденційність даних. Для здійснення цього завдання передбачено
AES-шифрування на декількох рівнях:
• З використанням унікального ключа мережі (Unique Network key,
EUI64) - на мережевому рівні
• За допомогою унікального ключа додатки (Unique Application key,
EUI64) - наскрізна безпеку на рівні додатків
• За допомогою спеціального ключа пристрою (Device specific key,
EUI128).
Класи пристроїв в мережі LoRaWAN.
Для вирішення різних завдань і застосувань в мережі LoRaWAN
передбачено три класи пристроїв:
Кінцеві пристрої LoRa (кінцеві вузли, end-node) є елементами
LoRaWAN мережі системи LoRa, де вони виконують такі функції, як
вимір або управління і контроль. Вони розташовуються віддалено і
мають, як правило, батарейне живлення. Використовуючи мережевий
протокол LoRaWAN, ці кінцеві точки (endnode) можуть бути
налаштовані для зв'язку з шлюзом LoRa (концентратором або базовою
станцією). Дані в LoRaWAN мережі можуть передаватися в обидві
сторони, як від кінцевих точок (end-node) до сервера, так і назад. Точки
(end-node) передають дані не постійно, а включають передачу лише на
деякий проміжок часу (як правило на 1- 5 секунд), після закінчення якого
відкривається два часових вікна для прийому даних. Решту часу
трансивери кінцевих вузлів (end-node) знаходяться або в неактивному
стані (sleep), або в стані прийому, в залежності від класу пристрою (A,
B або С).

Клас A Вузол (end-node) передає дані на шлюз короткими

посилками за заданим графіком. Ініціатором обміну виступає сам
кінцевий вузол (end-node). Точка (endnode), як правило, не вимагає
отримання підтвердження свого повідомлення додатком (повідомлення
без квитанцій), однак протокол передбачає і повідомлення, на які
сервер додатків формує спеціальну відповідь, "квитанцію", а
мережевий сервер вибирає найкращий маршрут (шлюз) для відправки
підтвердження (ACK від англ. acknowledgment - підтвердження) в
момент відкриття вузлом вікна прийому (повідомлення з квитанціями).
Вузол (end-node) переходить в режим прийому (відкриває вікно
прийому) відразу після відправки даних на деякий нетривалий час, в
іншому випадку, більш тривалий час, знаходиться в режимі
енергозбереження або сну (sleep). Сервер накопичує для точок (end-
node) повідомлення і пересилає їх відразу, як точка (end-node)
виходить на зв'язок. Цей клас кінцевих (end-node) вузлів найбільш
економічний у використанні енергії та найбільш поширений на практиці.
Повідомлення Unicast.
Отже, пристрої класу А після кожної передачі відкривають два
коротких тимчасових вікна на прийом (позначаються як RX1 і RX2).

Інтервали від кінця передачі до відкриття першого і другого

часових вікон можуть конфигурироватись, але повинні бути
однаковими для всіх пристроїв в даній мережі (RECEIVE_DELAY1,
RECEIVE_DELAY2). Для європейського діапазону 868 МГц
рекомендоване значення RECEIVE_DELAY1 становить 1 секунду.
Значення RECEIVE_DELAY2 має дорівнювати (RECEIVE_DELAY1 + 1)
секунда.
Використовувані частотні канали і швидкості передачі для
інтервалів RX1 і RX2 можуть відрізнятися. Рекомендовані значення
наведені в окремому документі - «LoRaWAN Regional Parameters»,
доступному на сайті LoRa Alliance.
Пристрої класу А є найбільш низькоспоживаючі, але для передачі
повідомлення від сервера до кінцевого пристрою необхідно дочекатися
наступного вихідного повідомлення від цього пристрою.
Клас B. Вузол (end-node) включає приймач за графіком, заданого
сервером. Сервер відправляє повідомлення вузлу (end-node)
відповідно до розкладу. Ініціатором обміну може бути і сервер
LoRaWAN мережі. Пристрої (end-node) цього класу синхронізують
внутрішній час з часом мережі за допомогою маячків (від англ. Beacon),
які пристрій регулярно отримує від шлюзу. Всі шлюзи, що входять до
складу однієї мережі, повинні випромінювати маячки одночасно.
Маячок містить ідентифікатор мережі і мітку часу (UTC). Вузли (end-
node) цього класу мають відносно низьку часову затримку в обміні
даними і відкривають додаткові вікна приймання за розкладом в
порівнянні з класом А. Точки (end-node) класу B також мають всі
можливості пристроїв (end-node) класу А.
Повідомлення Unicast та Multicast.
Клас C У точок (end-node) цього класу вікно прийому відкрито
постійно і закривається тільки на період короткочасної передачі даних.
Сервер може ініціювати обмін в будь-який час, і передати повідомлення
вузлу (end-node) відразу, у міру їх появи. Цей клас пристроїв (end-node)
споживає найбільшу кількість енергії (в порівнянні з класами A і B), тому
зазвичай не використовує батарейне живлення, але отримує дані від
сервера LoRaWAN мережі з найменшими затримками (lowest latency).
Пристрої класу С (end-node) мають всі можливості пристроїв класу А і
B. Точки (end-node) можуть проводити обмін як з одним, так і з
декількома шлюзами, вузли можуть працювати в двох режимах: точка-
точка (від англ. P2P - point to point), коли обмін відбувається між
кінцевим пристроєм (end-node) і шлюзом (також цілком реалізуємий
обмін тільки між двома вузлами (end-node) без використання
концентраторів і навіть сервера) і в гібридному режимі, коли один з
вузлів підключений, з одного боку, по радіоканалу до інших вузлів, а з
іншого боку, має дротове підключення до мережі по TCP/IP і виступає
в ролі шлюзу (використовуючи програмне забезпечення
packet_forwarder). Такий одноканальний міні-шлюз може обслуговувати
від одного до декількох десятків кінцевих пристроїв, які будуть
конкурувати між собою за вільні тайм слоти (від англ. Time slot)
мінішлюзу для прийому і передачі даних.
Повідомлення Unicast та Multicast.
Отже, пристрої класу C знаходяться в режимі прийому практично
весь час за винятком проміжків, коли вони передають повідомлення. За
винятком тимчасового вікна RX1 термінал використовує параметри
прийому RX2.

Клас С може застосовуватися там, де не потрібно щосили

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

Шлюзи (концентратори) LoRa. Шлюзи LoRa призначені для

використання в радіальних зіркоподібних мережевих архітектурах
великого радіусу дії в системі LoRaWAN. Через властивості технології
LoRa ці шлюзи можуть являти собою багатоканальні мультимодемні
трансивери, які здатні виконувати демодуляцію відразу декількох
каналів одночасно, і навіть одночасну демодуляцію множини сигналів
на одному і тому ж каналі. Ці шлюзи використовують інші радіочастотні
компоненти, ніж ті, які застосовуються в кінцевій точці (end-node) для
забезпечення високої ємності мережі. Шлюзи служать в якості
інтерфейсу у вигляді прозорого моста для передачі повідомлень між
кінцевими вузлами (end-node) і центральним сервером. Зв'язок між
концентраторами і центральним сервером LoRaWAN мережі оператора
(транспортна backhaul мережа) здійснюється за допомогою
традиційних технологій (Ethernet, WiFi, GSM) по протоколу TCP/IP.
Якщо шлюзи підключаються до мережевого сервера через стандартні
IPз'єднання, то кінцеві вузли (end-node) використовують бездротове
підключення до одного або кількох шлюзів. Всі кінцеві точки (end-node),
як правило, є двонаправленими, але вони також підтримують і
функціонування в режимі, що забезпечує можливість здійснення
групового оновлення програмного забезпечення через стільникову
мережу або передачу інших масових повідомлень (Broadcast), що
дозволяє скоротити час на їх передачу. Залежно від бажаної їх
канальної ємності і місць установки доступні різні версії шлюзів, вони
можуть встановлюватися як всередині приміщень (indoor), так і на
вишках або будівлях (outdoor). Вузли (end-node) LoRaWAN мережі
можуть бути в зоні покриття як одного шлюзу так і декількох. Шлюзом в
мережах з високою щільністю абонентських пристроїв виступають
спеціальні багатоканальні концентратори, які мають можливість
приймати дані від декількох вузлів одночасно. Саме ця можливість
шлюзу безпосередньо впливає на максимальну щільність
абонентських пристроїв (end-node) на ділянці місцевості, яка
обслуговується одним концентратором. Концентратори на базі
Semtech SX1301 мають можливість обслуговувати до 5 тисяч
абонентських пристроїв на один квадратний кілометр (на борту 2 чіпа
SX1257, що забезпечують подвійний RF фронтенд (від англ. Front-end)
на 8 незалежних каналів, які можуть працювати одночасно, і одним
транспортним backhaul каналом). Ємність мережі залежить від того
числа пакетів, які можуть бути отримані в даний момент часу. Один
шлюз на SX1301 з 8 каналами, використовуючи протокол LoRaWAN,
здатний отримати близько 1,5 млн. пакетів в день. Так що, якщо ваш
вузол відправляє один пакет на годину, то один шлюз на SX1301 може
з успіхом обслуговувати до 62500 таких кінцевих пристроїв. Зараз
ведеться серйозна боротьба серед прихильників різних IoT технологій
і в порівняльних таблицях, де кожен нахвалює сам себе, ви побачите
різну кількість вузлів (end-node), що обслуговуються одним шлюзом: від
декількох сотень до мільйонів. Такі дані неінформативні і можуть ввести
читача в оману, оскільки кожен вузол (end-node) може відправляти дані
з різною періодичністю, обсяг даних і швидкість передачі можуть
істотно відрізнятися, тому говорити про теоретичну ємності мережі
досить складно і для точних розрахунків потрібно брати до уваги безліч
чинників. Якщо ємності сегмента мережі недостатньо, то LoRaWAN
мережа масштабується: більш високу щільність вузлів (end-node), що
досягається шляхом установки додаткових шлюзів. При появі нового
шлюзу, центральний сервер мережі перерозподіляє навантаження,
відправляючи кінцевим вузлам "новий графік" включення режиму
передачі. Центральний сервер LoRaWAN мережі Проблему можливих
колізій при одночасній передачі даних декількома точками вирішує
центральний сервер LoRaWAN мережі, який адресно відправляє
вузлам (end-node) мережі керуючі команди через шлюзи, виділяючи
тайм-слоти для передачі і прийому індивідуально для кожної кінцевої
точки (end-node). Адресація відбувається по 32-бітному DevAddr,
унікальному для кожного вузла (end-node). Центральний сервер
LoRaWAN мережі приймає рішення про необхідність зміни швидкості
передачі даних точками (end-node), потужності передавача, виборі
каналу передачі, її початку і тривалості за часом, контролює заряд
батарей кінцевих вузлів (end-node), тобто повністю контролює всю
мережу і управляє кожним абонентським пристроєм окремо. Кожен
LoRaWAN пакет даних, що відправляються кінцевим вузлом, (end-node)
має в своєму складі унікальний ідентифікатор додатку AppEUI, що
належить додаткам на сервері сервіс-провайдера, для якого він
призначений і цей ідентифікатор використовується центральним
сервером LoRaWAN мережі для подальшої маршрутизації пакета і його
обробки додатком на сервері (App Server) сервіс-провайдера. На
практиці, як правило, послуги сервіс-провайдера надає виробник
кінцевих пристроїв (end-node), який підтримує сервіс для обробки
даних, куди маршрутизуються пакети з сервера LoRaWAN мережі для
роботи. Як окремий випадок, сервер додатків, сервер мережі і єдиний
шлюз мережі (у вигляді одноканального LoRa трансивера) можуть бути
об'єднані для побудови спрощеної моделі мережі в лабораторних
умовах. Програмне забезпечення ядра мережевого сервера вільно не
поширюється, але може бути отримано після укладення угоди з Lora
Alliance, в загальному доступі знаходиться демонстраційна
документація. Стійкість до радіоперешкод Висока проникаюча
здатність радіосигналу субгігагерцового діапазону в будівлях і підвалах
забезпечує стабільний зв'язок там, де інші бездротові технології
виявляються безсилі. Модем LoRa на суміщеному GMSK каналі має
можливість придушення перешкод до 19,5 дБ (за рахунок гауссової
фільтрації) або, кажучи іншими словами, він може приймати і
демодулювати сигнали на 19,5 дБ нижче рівня перешкод або шумів при
тому, що для правильної демодуляції більшості систем з частотною
маніпуляцією FSK (від англ. Frequency Shift Keying) потрібна потужність
сигналу, як мінімум на 8-10 дБ вище рівня шуму. Цей імунітет до
перешкод дозволяє використовувати просту і недорогу систему з LoRa
в тих місцях, де є важка спектральна обстановка (як в будь-якому
сучасному мегаполісі) або в гібридних мережах зв'язку. У цих випадках
використання технології LoRa дозволяє розширити діапазон покриття
мережі зв'язку.
Швидкість в LoRaWAN мережах
Адаптивна швидкість передачі даних ADR (Adaptive Data Rate) в
LoRaWAN мережах LoRaWAN протокол регламентує швидкість
радіообміну від 300 біт/с до 50 кілобіт в секунду, швидкість падає зі
збільшенням відстані між приймачем і передавачем. Фактично в
існуючих пристроях, швидкість, може не перевищувати 11 кілобіт в
секунду, що цілком достатньо для розв'язуваних даною технологією
завдань. Для Європи доступний один GFSK канал (від англ. Gaussian
Frequency-Shift Keying - модуляція у вигляді частотної маніпуляції, при
якій використовується фільтр Гаусса для згладжування) передачі
інформації з потоком даних до 50 кбіт/с. У Північній Америці, через
обмеження, що накладаються FCC (Federal Communications
Commission - Федеральна Комісія Електрозв'язку США), мінімальна
швидкість передачі даних становить 0,9 кбіт/с.
 Щоб продовжити термін служби батареї (акумулятора) в
кінцевому вузлі (endnode) і оптимізувати загальну пропускну здатність
мережі, мережевий сервер LoRaWAN управляє швидкістю передачі
даних і потужністю радіочастотного виходу кожного кінцевого пристрою
(end-node) окремо на підставі відстані від шлюзу. Управління
здійснюється за допомогою алгоритму адаптивної швидкості передачі
даних ADR (від англ. Adaptive Data Rate). Це має вирішальне значення
для високої продуктивності мережі і дозволяє здійснювати її необхідну
масштабованість. Адаптивна швидкість передачі даних ADR (Adaptive
Data Rate) представляє собою метод, при якому фактична швидкість
передачі даних регулюється таким чином, щоб забезпечити надійну
доставку пакетів, забезпечити оптимальну продуктивність мережі і
необхідний масштаб для її завантаження. Так, наприклад, вузли (end-
node) ближчі до шлюзу використовуватимуть і більш високу швидкість
передачі даних (а, отже, більш короткий час активної передачі по
радіоканалу) і меншу вихідну потужність. Тільки найвіддаленіші точки
(end-node) будуть використовувати низьку швидкість передачі даних і
високу вихідну потужність передавача. Технологія адаптивної
швидкості передачі даних ADR може внести необхідні зміни в мережеву
інфраструктуру і, таким чином, компенсувати різні втрати на трасі
передачі сигналу. LoRaWAN мережа може бути розгорнута з
мінімальними інвестиціями в інфраструктуру і з тією її ємністю, яка
конкретно потрібна для даного застосування. Якщо розгорнуто багато
шлюзів, то технологія ADR буде зміщувати швидкість передачі даних в
сторону підвищення, що забезпечить масштабування ємності мережі в
межах від 6 до 8 раз. Протокол LoRaWAN визначає конкретний набір
швидкостей передачі даних, але крайовий чіп або так званий фізичний
шар (PHY, OSI media layer 1), тобто сама інтегральна схема,
призначена для виконання функцій фізичного рівня мережевої моделі
OSI, здатна дати більше варіантів. Наприклад, Semtech SX1272
підтримує швидкості передачі даних від 0,3 до 37,5 кбіт/с, а SX1276 від
0,018 до 37,5 кбіт/с.
Безпека в LoRaWAN мережах
Для захисту від несанкціонованого доступу і спотворення або
перехоплення даних, переданих кінцевими пристроями (end-node), в
LoRaWAN мережах стандарту передбачено обов'язкове дворівневе
шифрування даних двома різними AES-128 ключами по RFC-4493.
Забезпечується повна конфіденційність даних при проходженні всіх
задіяних в ланцюжку пристроїв, тому вміст пакета доступно тільки
відправнику (кінцевій точці) і одержувачу, для якого воно призначене,
тобто додатком сервіс-провайдера. Сервер мережі оперує даними в
зашифрованому вигляді, виробляє аутентифікацію і перевіряє
цілісність кожного пакету, але при цьому не має доступу до корисного
навантаження (від англ. Payload), тобто до інформації від підключених
до вузла сенсорів.

6.3. SigFox
SigFox - технологія бездротового зв'язку пристроїв в мережах з
низьким споживанням енергії низкоскоростной.
Технологія SigFox була винайдена і запатентована в 2009 році
французькою компанією з однойменною назвою. SigFox - приватна
компанія, яка побудувала нову технологію IoT з нуля і зробила її
доступною як відкритий стандарт. Перша мережа SigFox була
розгорнута у Франції в 2012 році, а до 2014 року було забезпечено
загальнонаціонального покриття країни для підключення об'єктів малої
потужності, таких як лічильники електроенергії та смарт-годинники , які
потребують постійного включення та випромінювання невеликої
кількості даних.
До 2015 року SigFox планувала вийти на американський ринок,
але зіткнулася з проблемами в дозволеному в США частотному
діапазоні, тому що частотний діапазон, який використовується в США
більш схильний до перешкод, ніж європейський діапазон. У той же час
технологія SigFox поширилася на країни Азіатсько-Тихоокеанського
регіону.
Політика SigFox має на увазі надання відкритої інформації про
необхідному для побудови мережі апаратному забезпеченні (базових
станціях і модулях), при цьому програмне забезпечення є закритим і
продається операторам як послуга. В даний час SigFox присутній в
більш ніж 60 країнах. Однак в Україні мережі SigFox ще немає.
Технічні характеристики
Для передачі даних SigFox використовує ультра-вузьку смугу
частот (Ultra- Narrow Band, UNB) з двійково-фазовою маніпуляцією
(BPSK), а для кодування даних змінює фазу несучої радіохвилі. Це
дозволяє зменшити рівень шуму на приймаючій стороні, отже, зробити
приймають пристрою більш дешевими.
 радіус дії: 30-50 км (3-10 км в зашумлених і важкодоступних
районах);
 Швидкість передачі бітів залежить від пропускної здатності регіону
застосування. Якщо пропускна здатність, що використовується
для передачі, становить 100 Гц, то в цьому випадку швидкість
передачі бітів становить 100 біт/с. При зайнятості пропускної
здатності передачі потужністю 600 Гц дозволяє отримати
швидкість передачі даних в 600 біт / с
 термін служби пристроїв без заміни батареї: 20 років від 2-х
батарейок типу АА;
 використовувані частоти: 868 МГц (Європа) і 902 МГц (США);
 топологія мережі: зірка (базова станція, до якої підключаються
кінцеві точки).
Існуючий стандарт SigFox визначає максимальну кількість
повідомлень від базової станції до кінцевого пристрою в день: 140
повідомлень, при цьому кожне повідомлення має бути розміром не
більше 12 байт (виключаючи заголовок повідомлення та інформацію
про передачу). І також кількість повідомлень, що виходять від кінцевого
пристрою: 4 повідомлень в день з корисним навантаженням 8 байт.

Фізичний рівень
В Sigfox реалізується двонаправлений зв'язок. Однак
двонаправленй зв'язок в Sigfox вимагає деякого пояснення. Режим
пасивного прийому відсутній, що означає, що базова станція не може
просто відправити повідомлення на пристрій кінцевої точки в будь-який
час.
В Sigfox процедура передачі даних, яка ініціюється мережевим
вузлом називається низхідною лінією зв’язку. А процедура передачі
даних мережевому вузлу – повідомлення з висхідної лінії зв'язку.
Процедура зв'язку за низхідній лінії зв'язку ініціюється
мережевим вузлом і тому не може бути передана пристрою в будь-який
час.
Вікно прийому відкривається для зв'язку тільки після завершення
вікна передачі. Вікно прийому відкривається тільки після 20-секундного
періоду, коли перше повідомлення було відправлено вузлом кінцевої
точки. Вікно залишиться відкритим протягом 25 с, що дозволить
отримати коротке (4 байтне) повідомлення від базової станції. У Sigfox
повідомлення відправляється три рази на трьох різних частотах в три
різних напрямки вузлом, що допомагає забезпечити цілісність передачі
повідомлення. Для передачі даних використовуються 333 канали
шириною 100 Гц. Чутливість приймача становить -120 дБм/-142 дБм.
Частотний стрибок підтримується з використанням псевдовипадкового
методу 3-х з 333 каналів.

Рис.6.5. Тимчасова шкала передачі Sigfox. Три копії корисного

навантаження передаються на трьох унікальних випадкових частотах
з різними часовими затримками

Рівень MAC Sigfox

Кожен пристрій в мережі Sigfox має унікальний ідентифікатор
Sigfox. Ідентифікатор використовується для маршрутизації і
підписування повідомлень. Ідентифікатор використовується для
автентифікації пристрою Sigfox. Ще одна характеристика зв'язку Sigfox
полягає в тому, що він діє як «спалити і забути». Одержувачі не
підтверджують повідомлення. Модель «спалити і забути» не має
можливості гарантувати, що повідомлення дійсно отримано, тому
передавач повинен робити якомога більше, щоб забезпечити точну
передачу. На рівні MAC пристрій, який хоче передавати дані,
інкапсулює його в пакет (рис. 6.6) і три рази передає на різних
випадкових частотах з різним канальним кодуванням при кожній
передачі.
SIGFOX - це асинхронна технологія (як і LoRa) - вузлам не
потрібно прокидатися для синхронізації. Отже, модель
енергоспоживання SIGFOX простіша, ніж для інших технологій: вузли
перебувають у стані Tx під час передачі даних та у режимі сну між
передачами.

Формат кадру Sigfox MAC, що передається пристроєм

Преамбу Синхроніза ID Корисне Автентифіка Контроль
ла ція кадра адреса навантаже ція на сума
16 біт та ння 16 біт
32 біта 32 біта від 0 до 64 варіюється
біт

Формат кадру Sigfox MAC, який надходить на пристрій

Преамбу Синхронізац Прапорці Контроль Автенти Коди Корисне
ла ія 2 біта на сума фі помилок навантажен
кадра 16 біт кація варіюєть ня
32 біта 13 біт 16 біт ся від 0 до 64
біт

Рис.6.6. Структура пакета кадров Sigfox MAC

Кадри містять преамбулу зумовлених символів,

використовуваних для синхронізації при передачі. Поля синхронізації
кадру визначають типи переданих кадрів. FCS - це контрольна
послідовність кадрів (FCS), яка використовується для виявлення
помилок.
Пакет не містить адресу призначення або інший вузол. Всі дані
будуть відправлятися різними шлюзами в хмарну службу Sigfox.

Стек протоколу Sigfox

Стек протоколу аналогічний іншим стекам, наслідуючи модель
OSI (табл. 7.8). Існує три рівні:
 рівень PHY - синтезує і модулює сигнали з використанням
DBPSK в напрямку висхідної лінії зв'язку і GFSK в напрямку низхідної
лінії зв'язку, як описано раніше;
 рівень MAC - додає поля для ідентифікації / автентифікації
пристрою (HMAC) і код виправлення помилок (CRC). Sigfox MAC не
надає ніякої сигналізації. Це означає, що пристрої не синхронізуються
з мережею;
 рівень кадру - генерує радіокадр з даних програми. Крім того,
систематично прикріплює порядковий номер до кадру
 рівень додатків визначає різні додатки відповідно до вимог
користувача, а саме. Інтернет, повідомлення та інш.
 Номер рівня OSI модель Мережа
7 Прикладний
6 Представлення Прикладний
5 Сеансовий
4 Транспортний
Frame
3 Мережевий
2 Канальний MAC
1 Фізичний PHY Радіоканал 868 МГц, 902 МГц
Рис. 6. 7. Архітектура стека Sigfox і спрощена модель OSI

Що стосується безпеки, повідомлення не шифруються ні в якому

місці стека протоколів Sigfox. Клієнт повинен надати схему
шифрування для даних корисного навантаження (рівень 7 або 6 моделі
OSI). Ніякі ключі не обмінюються через мережу Sigfox, однак кожне
повідомлення підписується ключем, унікальним для ідентифікації
пристрою.

Топологія Sigfox
Мережа Sigfox може бути щільною, як один мільйон вузлів на
базову станцію (рис. 6.8). Щільність - це функція кількості повідомлень,
відправлених мережевими пристроями. Всі вузли, які приєднуються до
базової станції, утворюють зіркому мережу.
Об'єкти передають свої повідомлення на базову станцію
SigFox. Посилання "точка-точка" підключають базову станцію Sigfox до
її Інтернет-бази даних (служби), і після отримання та розшифровки
повідомлення, дані надсилаються до його Інтернет-бази даних.Далі,
хмарний сервер SigFox передає повідомлення на сервери клієнтів та
ІТ-платформи через API (інтерфейс програмування прикладних
програм).
 Рис. 6.8 Топологія Sigfox. Sigfox використовує свій власний
протокол, відмінний від IP, і об'єднує дані в мережевий сервер Sigfox,
як дані IP

Всі дані управляються через бекенд-мережу Sigfox. Всі

повідомлення з базової станції Sigfox повинні надходити на внутрішній
сервер через IP-з'єднання. Служба хмарних обчислень Sigfox є єдиним
місцем призначення пакета. Бекенд буде зберігати і відправляти
повідомлення клієнту після його автентифікації і перевірки відсутності
дублікатів. Якщо дані повинні бути передані вузлу кінцевої точки,
бекенд-сервер буде вибирати шлюз з найкращим підключенням до
кінцевої точки і пересилати повідомлення пристрою. Бекенд
ідентифікує пристрій за ідентифікатором пакета.
Бекенд - це також адміністрування, ліцензування та надання
послуг для клієнтів. Хмара Sigfox передає дані в пункт призначення,
обраний клієнтом. Хмарний сервіс пропонує можливість інтеграції
хмарних функцій Sigfox з сторонньої платформи. Пристрої можуть бути
зареєстровані через іншу хмарну службу. Sigfox також пропонує
зворотні виклики для інших хмарних сервісів. Щоб допомогти
забезпечити цілісність даних в моделі зв'язку, кілька шлюзів можуть
отримувати передачу від вузла; всі наступні повідомлення будуть
перенаправлені на бекенд Sigfox, а дублікати будуть видалені. Це
додає рівень надмірності до прийому даних.
Sigfox - одна з найбезпечніших технологій LP-WAN. Пристрої Sigfox
переважно працюють в автономному режимі з вбудованою поведінкою.
Коли Sigfox потрібно передавати або отримувати дані з Інтернету,
пристрій Sigfox передає радіоповідомлення. Це широкомовне
повідомлення приймається базовими станціями, і потім повідомлення
передається в базову мережу Sigfox, яка потім доставляється
відповідними програмами IoT.
Передбачено в Sigfox кілька механізмів безпеки, спочатку
підтримується: наскрізна автентифікація. Протокол Sigfox визначає
мережевий ключ автентифікації (NAK) - це секретний симетричний
ключ, що надається для кожного пристрою (зберігається в його
захищеної області пам'яті під час виробництва), спільно
використовуваний з сервером, і ідентифікатор кінцевого пристрою, який
дозволяє мережному серверу ідентифікувати пристрій. Щоб
гарантувати послуги автентичності та цілісності, всі повідомлення
відправляються пристроєм Sigfox за кодом аутентифікації повідомлень.

6.4. Технологія NB-IoT

Нова технологія вузькосмугового бездротового інтернету речей
NB-IoT (Narrowband Internet of Things) розроблена у 2016 році
консорціумом 3GPP і є розширенням традиційного ліцензійного
стандарту стільникового зв'язку для пристроїв IoT, та використовує
існуючу інфраструктуру мереж операторів зв'язку.
NB-IoT можна порівняти з LTE (4G).
Технологія NB-IoT використовує переваги мережі 4G:
інфраструктура, діапазон та безпека, оскільки характеризується
відмінним покриттям і широким діапазоном.
За технологією NB-IoT можна підключати до однієї соти базової
станції до 100 тисяч пристроїв, що в десятки разів перевищує
можливості існуючих стандартів мобільного зв'язку.
NB-IoT є одним з трьох стандартів IoT, розроблених 3GPP для
стільникових мереж зв'язку: eMTC (enhanced Machine-Type
Communication), NB-IoT і EC-GSM-IoT. eMTC володіє найбільшою
пропускною спроможністю і розгортається на обладнанні LTE. NB-IoT
мережа може бути розгорнута як на обладнанні стільникових
мереж LTE , так і окремо, в тому числі поверх GSM. EC-GSM-IoT надає
найменшу пропускну здатність і розгортається поверх мереж стандарту
GSM.
Використання низькочастотного діапазону (ширина смуги одного
каналу - 180 кГц) дозволить забезпечити широку область покриття, а
саме важкодоступні місця, цокольні приміщення, підвали та інше.
Крім того, при роботі в новому стандарті пристрої економніше
витрачають заряд акумулятора, що дозволяє їм працювати без
додаткового живлення до 10 років служби при використанні до 200 байт
на день.
NB-IoT відповідає вимогам ринку LPWAN, дозволяючи телеком-
операторам працювати з вже традиційними напрямками IoT, такими як
«розумні» датчики витрати води, газу, електрики, стеження за
об'єктами на базі наддешевих IoT-пристроїв, а також відкриває нові
можливості в таких галузях, як сільське господарство, охорона
здоров'я, системи забезпечення безпеки, транспорт, логістика.

Мобільний оператор компанія "Vodafone Україна" в 2019 році

завершив тестування власної мережі NB-IoT (Narrow Band Internet of
Things) в Києві. Тестування проведено на фрагментах мережі "Vodafone
Україна" в Києві з використанням клієнтського обладнання, наданого
для тестів "Київводоканалом" - спеціальних модулів для Smart metering
з автоматизованою передачею показань, що мають ультранизьким
енергоспоживанням як в режимі очікування, так і в режимі обміну
даними. "При підключенні таких пристроїв до NB-IoT мережі вдається
досягти економного використання ресурсів і збільшити термін служби
батарей до 10 років", - підкреслюють в "Vodafone Україна". Оператор
також повідомляє, що розгортання технології NB-IоT виконується на базі
мережі LTE (на виділеній частоті 1800 МГц), має високий стандарт
безпеки - шифрування і аутентифікацію на базі sim-карти, недоступні в
таких технологіях як LoRa.

Консорціумом 3GPP пропонує три сценарії розгортання мережі

NB-IоT (три способи виділення частотного ресурсу для NB-IoT):
1. Stand-alone operation (автономний режим роботи). Одним з
можливих сценаріїв є виділення одного частотного інтервалу 200кГц в
діапазоні GSM, що дозволяє організувати NB-IoT радіоканал з двома
захисними інтервалами по 10кГц.
 Між несучими GSM

2. In-band operation (робота в смузі мережі LTE) - виділення

одного ресурсного блоку в робочій смузі частот, використовуваної для
надання послуг LTE.
Сценарій суміщеної роботи (In-band) коли для пристроїв NB-IоT
використовуються ресурсні радіоблоки всередині існуючих
радіоканалів, діючих мереж LTE, які мають найбільше покриття і
забезпечують необхідну якість обслуговування Інтернету речей. Це
оптимальний шлях для підключення IoT, оскільки він дозволяє
операторам зв'язку використовувати сучасне обладнання без істотних
змін апаратного забезпечення. Таким чином in-band NB-IoT дає
можливість задовольнити поточний попит на підключення розумних
пристроїв.
Швидкість передачі даних в NB-IoT досягає 200 Кбіт/с, що є
достатнім для пристроїв, періодично передають однотипні дані
невеликого обсягу.
 Разміщення NB-IoT в режимі guard-band

У цьому випадку для NB-IoT виділяються ресурси, що

знаходяться всередені існуючої LTE несучої частоти, але NB-IoT
несуча частота має більшу потужність на 6дБ за порівнянням з
ресурсними блоками LTE. Цей варіант добре підходить для економії
частотного ресурсу, але при цьому є проблема взаємного впливу з LTE-
мережею.
Найбільш поширеним є внутрішньсмуговий метод. Він широко
застосовується в Європі, де працює з NB-IoT в діапазоні роз'єднаних
телекомунікаційних компаній Vodafone, Deutsche Telekom, Telecom
Italia Mobile та інших.
Внутрішньсмугові можливості для розширення можуть
використовувати NB-IoT всередині існуючих мереж LTE, які мають
велике покриття і забезпечують необхідну якість обслуговування
Інтернету речей. Це оптимальний шлях для підключення IoT, оскільки
він дозволяє операторам звязку використовувати сучасне
обладнання, не маючи суттєвих змін апаратного забезпечення. Таким
чином, вбудований NB-IoT дає можливість задовольнити поточний
попит на підключення розумних пристроїв.
3. Guard band operation (робота в захисній смузі мережі LTE) -
виділення одного ресурсного блоку в захисному інтервалі за межами
робочої смуги частот, використовуваної для надання послуг LTE.
Зокрема, захисна смуга для діапазону LTE шириною 20МГц становить
1МГц з кожного боку, для діапазону LTE шириною 10МГц - по 500кГц.
 Технологія NB-IoT демонструє успішну інтеграцію технології в
мобільну мережу операторів стільникового зв’язку та використовує
переваги мережі LTE (4G) і може посісти місце лідера в розробці
рішень NB-IoT для різних вертикальних галузей, включаючи
комунальні послуги, сільське господарство, виробництво, натільні
електронні пристрої і транспорт, з метою створення досконалого
світу зв'язку.

Порівняльний аналіз NB-IoT і LoRaWAN

1. Простота розгортання.
NB-IoT - це стандарт стільникового зв'язку, тому для роботи
базових станцій необхідно отримати ліцензію. NB-IoT мережа працює в
ліцензованій частині спектра - на частотах, де запущені мережі 4G (від
1800 МГц і нижче). Тобто можна додатково використовувати
інфраструктуру 4G 1800, який в минулому році з'явився в Україні.
LoRaWAN - стандарт протоколу LPWAN, що працює в
технологічному середовищі LoRa. Для роботи LoRaWAN не потрібно
отримання ліцензій від держави на використання частот.
2. Синхронізація.
Через те, що мережа NB-IoT відноситься до стільникового зв'язку,
то пристрої, що працюють в ній, повинні «прокидатися» і
синхронізуватися з мережею. В іншому випадку отримати або
відправити повідомлення не вдасться. Кожен сеанс синхронізації
забирає в акумуляторного пристрою заряд енергії.
Устаткування в мережі LoRaWAN працює зовсім інакше.
Асинхронне надсилання даних передбачає передачу даних тільки тоді,
коли ці дані є. Поки пристрою нічого передавати, він у стані «сон»,
економлячи енергію. Можна також задати надсилання даних за
розкладом або незалежно від часу.
3. Час автономної роботи.
Оскільки NB-IoT працює в ліцензованому спектрі частот, пристрої
повинні синхронізуватися з мережею досить часто, що призводить до
швидкого розряду акумулятора типу АА.
В архітектурі LoRa синхронізація з мережею не потрібна при
використанні пристроїв LoRa класу А, С, що допомагає зберегти заряд
акумулятора.
4. Швидкість передачі даних.
Середня швидкість передачі даних в мережах NB-IoT - 200 Кбіт/с.
NB-IoT - це більш ефективний протокол IoT для «швидших» додатків.
Швидкість передачі даних в мережі LoRa становить від 300 біт/с
до 50 Кбіт/с, в міру віддалення від антени вона падає, і може опускатися
до 11 Кбіт/с, чого, по суті, все одно досить для передачі невеликих
обсягів даних.
5. Пропускна смуга
NB-IoT зазвичай працює на більш високій пропускній здатності,
ніж LoRaWAN і становить 180 кГц. LoRa використовує 125 КГц.
6. Покриття мережі
NB-IoT найкраще працює в складних міських районах.
Продуктивність мережі буде надлишковою в приміських або сільських
районах.
LoRaWAN не покладається на мобільні дані і її покриття
залишається відносно стійким незалежно від умов місцевості.
7. Управління SIM-картами.
Для роботи в мережі NB-IoT потрібна наявність SIM карти, які
можуть бути трьох різних форматів - звичайні, термо-SIM карти для
роботи в екстремальних кліматичних умовах, SIM-чіпи для невеликих
пристроїв.
Впровадження технології LoRa істотно посилило конкуренцію на
ринку бездротових технологій IoT для стільникових технологій, бо
працює без SIM карти і відповідно кінцевий вузол підключається до
мережі безкоштовно.
8. Розгортання мережі LPWAN в Україні.
 Оператор стільникового зв'язку lifecell планує розгортати мережу,
використовуючи технологію LoRaWAN та використовувати для цього
частоту у 868 МГц. Така технологія дозволить підтримувати зв'язок між
пристроями на відстані до 15 км при мінімальному споживанні енергії.
У свою чергу оператори стільникового зв'язку Київстар, і Vodafone
погоджуються, що в Україні потрібні окремі мережі IoT, і почали
розгортати мережу NB-IoT, яка дозволить забезпечити хороше
покриття в приміщеннях і підземних спорудах і обслуговувати
величезну кількість кінцевих пристроїв.
 6LoWPAN «IPv6 over Low-Power Wireless Personal Area Networks»
означає «передача пакетів IPv6 поверх малопотужних бездротових
персональних мереж», отже, 6LoWPAN є мережевою технологією або
рівнем адаптації, який дозволяє ефективно передавати пакети IPv6 в
невеликих фреймах канального рівня, визначених у бездротовому
стандарті IEEE 802.15.4.
Група 6LoWPAN передбачила можливість використовувати
інкапсуляцію та стислі заголовки, які дозволяють переходити та
пропускати пакети IPv6 в межах IEEE 802.15.4.
Характеристики 6LoWPAN роблять цей стандарт ідеальним для
автоматизації будівель, управління вуличним і домашнім освітленням,
застосування в системах інтелектуального обліку та інших типових
додатках «Інтернету речей».
Його переваги - стандартна IP-адресація, мале
енергоспоживання, надійна передача даних і робота в різних частотних
діапазонах. Передача даних в стандарті 6LoWPAN має на увазі
використання субгігагерцового діапазону і забезпечує швидкість
передачі від 50 до 200 Кбіт/с на відстань до 800 метрів.
Стандарт 6LoWPAN підключає безліч пристроїв до хмари. Мала
потужність, всі вузли IP-адресуються та підтримується велика кількість
комірчатстих мереж, що робить цю бездротову технологію хорошим
вибором для додатків Інтернету речей (IoT).

7.1. Архітектура 6LoWPAN-мережі

Архітектура мереж 6LoWPAN дещо відрізняється від традиційних
архітектур IP-мереж (наявність спеціалізованого комутаційного
обладнання, маршрутизаторів, медіа-конверторів) і від сформованих
архітектур бездротових мереж збору даних. Найближче до неї
знаходиться архітектура WiFi-мереж, хоча і від неї є ряд відмінностей.
Перш за все, мережі 6LoWPAN є подмережами IPv6-мереж, тобто
вони можуть взаємодіяти з іншими мережами і вузлами IP-мережі, але
не є транзитними для її мережевого трафіку. Мережі 6LoWPAN
складаються з вузлів, які можуть також виконувати роль
маршрутизаторів (host і router), крім цього в мережі може бути присутнім
один або більше так званих граничних маршрутизаторів (edge routers).
Участь в маршрутизації не є обов'язковою вимогою для вузла мережі і
він може грати роль кінцевого пристрою або пристрою з обмеженою
функціональністю для мереж 802.15.4, в термінології 6LoWPAN - «хост-
вузол» Н (host). Вузол, здатний виконувати маршрутизацію в межах
мережі 6LoWPAN, називається роутером або маршрутизатором R
(router).
Граничний маршрутизатор необхідний для архітектури
6LoWPAN, оскільки він має чотири функції:
 бере участь в процедурі ініціалізації і маршрутизації в
підмережі 6LoWPAN
 підтримує зв'язок з пристроями 6LoWPAN і передає дані в
інтернет (відповідає за взаємодію підмережі 6LoWPAN з мережею IPv6)
 виконує стиснення заголовків (компресію/декомпресію) IPv6,
зменшуючи 40-байтовий заголовок IPv6 і 8-байтний UDP-заголовк для
підвищення ефективності в мережі датчиків. Типовий 40-байтовий
заголовок IPv6 може стискатись до 2-20 байт в залежності від
використання;
 в разі підключення до мережі IPv4 може грати роль шлюзу
IPv6↔IPv4.
Існує три типи вузлів в mesh-мережі 6LoWPAN:
 вузли маршрутизатора - ці вузли направляють дані з одного
вузла сітки 6LoWPAN на інший. Маршрутизатори також можуть
передавати інформацію в WAN і інтернет;
 вузли хоста - хости в mesh-мережі не можуть
маршрутизувати дані в мережі і є просто кінцевими точками, що
утримують або створюють дані. Хостам дозволено перебувати в стані
сну і іноді прокидатися для отримання даних самим або отримання
даних, кешованих їх батьківськими маршрутизаторами;
 граничні маршрутизатори: як зазначено, це шлюзи і
контролери сітки, зазвичай на краю WAN. Mesh-мережа 6LoWPAN буде
управлятися граничним маршрутизатором.
Вузли підмережі поділяють 64-бітний префікс IPv6, який також є
частиною мережної адреси граничного маршрутизатора. Для адресації
всередині мережі можна використувати решту 64 біти (MAC-адресу
мережевого інтерфейсу) або використовувати стиснення адреси і
вкорочену 16-бітну схему адресації (молодші два байти MAC-адреси).
Передбачається, що мережева адреса безпосередньо включає
адресу мережевого інтерфейсу, це виключає необхідність застосування
протоколу визначення мережевих адрес ARP (Address Resolution
Protocol).
 Виділяють три типи мереж 6LoWPAN (рис. 7.1):
 ad-hoc (самоорганізована, динамічна);
 проста 6LoWPAN-мережа;
 розширена 6LoWPAN-мережа.

Рис. 7.1 - Типи мереж 6LoWPAN (R- маршрутизатор, Н - хост)

Ad-hoc-мережа не має підключення до зовнішньої IP-мережі, не

має граничного маршрутизатора. Є мережею, що самоорганізується, та
використовує стек протоколів 6loWPAN для організації роботи та
передачі даних між вузлами.
Проста 6LoWPAN-мережа підключена до іншої IP-мережі за
допомогою одного граничного маршрутизатора. Граничний
маршрутизатор може бути підключений до зовнішньої IP-мережі
безпосередньо (підключення типу «точка-точка», наприклад, GPRS/3G-
модем) або може входити до складу кампусної мережі (наприклад,
мережі організації).
Розширена 6LoWPAN-мережа складається з однієї або
декількох підмереж, підключених до зовнішньої IP-мережі через кілька
граничних маршрутизаторів, підключених до однієї мережі (наприклад,
локальна мережа організації). При цьому граничні маршрутизатори в
розширеній мережі поділяють один і той же мережевий префікс. Вузли
розширеної мережі можуть вільно переміщатися в межах мережі та
здійснювати обмін із зовнішньою мережею через будь-який граничний
маршрутизатор (зазвичай вибирається маршрут з найкращими
показниками якості сигналу - рівень помилок, рівень сигналу).

7.2. Стек 6LoWPAN

Взаємодія між вузлами в мережі 6LoWPAN, а також взаємодія з
зовнішніми вузлами здійснюється так само, як і в звичайній IP-мережі.
Кожен вузол має свій унікальний IPv6-адрес і може приймати і
передавати пакети IPv6. Зазвичай вузли мають підтримку протоколу
ICMPv6 і UDP. Прикладні протоколи найчастіше використовують
бінарний формат даних при роботі з UDP-протоколом в мережах
6LoWPAN. На відміну від TCP/IP-стека, в 6LoWPAN немає підтримки
протоколу транспортного рівня TCP - через великі накладні витрати на
формування пакетів і через особливості роботи протоколу, які суттєво
ускладнюють його застосування в сенсорних бездротових мережах
(підтвердження пакетів і встановлення/втрата з'єднання, що в свою
чергу вимагає частої роботи приймача вузла, і, як наслідок, підвищеного
споживання енергії). Порівняння стеків протоколів TCP/IP, 6LoWAPN
(рис. 7.2.)

Рис. 7.2 - Порівняння стеків протоколів TCP/IP, 6LoWAPN

 Фізичний рівень перетворює біти даних в сигнали, які
передаються і виходять по ефіру. У 6LoWPAN, наприклад,
використовується IEEE 802.15.4. На додаток до широко відомої версії
стандарту 2006 року існують дві важливі поправки: e і g. IEEE 802.15.4e
- поправка до MAC, вона пропонує такі розширення, як перемикання
каналів з виділенням квантів часу (TSCH - time slotted channel hopping) і
координоване виборче прослуховування (CSL - coordinated sampled
listening). Обидва розширення націлені на додаткове зниження витрати
енергії і роблять бездротовий інтерфейс більш стійким. IEEE 802.15.4g
- поправка до PHY (фізичного рівня), мета якої - забезпечити додатковий
діапазон радіочастот, щоб дозволити їх використання по всьому світу
навіть в діапазонах субгігагерцевих частот.
Канальний рівень забезпечує надійну передачу даних між
двома безпосередньо пов'язаними вузлами за рахунок виявлення та
виправлення помилок, які можуть виникнути на фізичному рівні під час
передачі і прийому. Канальний рівень включає рівень доступу до
середовища передачі (MAC), який використовує метод множинного
доступу з контролем несучої і винятком зіткнень (CSMA/CA), відповідно
до якого радіостанція прослуховує ефір, визначаючи, чи веде передачу
будь-яка інша станція, перед початком передачі даних по ефіру. Цей
рівень також забезпечує синхронізацію даних. У 6LoWPAN рівень MAC
визначається стандартом IEEE 802.15.4.
Рівень адаптації 6LoWPAN, забезпечує перехід від IPv6 до IEEE
802.15.4, також розташовується на канальному рівні.
Мережевий рівень підтримує адресацію і маршрутизацію даних
через мережу, якщо потрібно зробити кілька ретрансляції. IP
(міжмережевий протокол) - мережевий протокол, який використовується
для надання всіх пристроїв IP-адрес з метою транспортування пакетів
від одного пристрою до іншого.
Транспортний рівень відкриває сесії зв'язку між додатками, що
запускаються на кінцевих пристроях. Транспортний рівень дозволяє
декільком додаткам на кожному пристрої мати власний канал
зв'язку. TCP - домінуючий транспортний протокол в Інтернеті. Однак
TCP заснований на протоколі з'єднання (включаючи впорядкування
пакетів) з великим обсягом службової інформації і тому не завжди
підходить для пристроїв, що вимагають ультрамалих споживаннь
енергії. Для систем такого типу кращої опцією є є UDP - протокол без
встановлення з'єднання з меншим об'ємом службової
інформації. Прикладом безпечного транспортного рівня є протокол TLS
(безпека транспортного рівня), який виконується поверх TCP і DTLS і
заснований на UDP.
Прикладний рівень відповідає за форматування даних. Він
також перевіряє, чи дані транспортуються за оптимальною для
застосунку схемою. Широко використовується прикладний рівень в
Інтернеті - HTTP, що запускається поверх TCP. HTTP використовує XML
- текстову мову з великим об'ємом службової інформації. Тому не
оптимально використовувати HTTP в багатьох системах
6LoWPAN. Однак HTTP все ще може бути дуже корисним для зв'язку
між 6LoWPAN і Інтернетом. Тому промислові і громадські організації
розробили альтернативні протоколи прикладного рівня, наприклад
відомий вже нам, обмежений прикладний протокол (CоAP) - протокол
передачі повідомлень поверх UDP з біт-оптимізованим механізмом
REST. CоAP віднесений IETF в RFC 7252 і визначає ретрансляцію
повідомлень з підтвердженням і без, підтримки «сплячих» пристроїв,
передачу блоків, підтримку підписки і виявлення сервісів. CоAP також
легко перетворити в HTTP через проксі.
Ще один протокол прикладного рівня, який слід згадати, це
транспортний протокол черг повідомлень (MQTT) - протокол з відкритим
вихідним кодом, який був запропонований IBM. MQTT - це протокол
типу «видавець/підписник», що запускається поверх TCP. Дані не
транспортуються безпосередньо між кінцевими точками. Замість цього
використовується брокер (тобто сервер), який передає повідомлення.

7.3. Інтернет-протокол версії 6 (IPv6) поверх IEEE 802.15.4

Сучасний Інтернет (і безліч автономних IP-мереж) заснований
головним чином на IPv4 і використовує 32-бітові адреси. Він обмежує
адресний простір 4294967296 унікальними адресами. Оскільки адреси
присвоюються користувачам (і пристроїв), число не присвоєння адрес,
природно, зменшується. Вичерпання адрес IPv4 сталося 3 лютого 2011
року, хоча цей процес був значно відстрочений такими змінами в їх
розподілі, як трансляція мережевих адрес (NAT).
Це обмеження IPv4 стимулювало розвиток IPv6 в 1990-х роках,
його комерційне розгортання почалося з 2006 року. IPv6 покриває
адресний простір 2128, тобто має 3,4 • 1038 унікальних адрес. Цього
має бути достатньо для масштабування Інтернету протягом багатьох
десятиліть, в тому числі з перспективою росту «Інтернету речей», до
якого, згідно з оцінками, може бути підключено 50 мільярдів пристроїв
до 2020 року.
Щоб знайти можливість збільшення пропускної здатності, IPv6
максимальний розмір переданого блоку (MTU) від 576 до 1280 байтів. В
IPv6 також відображені зміни та удосконалення технологій
використання Інтернету на канальному рівні. Ethernet - домінуюча
технологія зв'язку, і його пропускна здатність збільшується рік від
року. У Wi-Fi, як і в Ethernet, підтримуються MTU аналогічного розміру і
дуже високі канальні швидкості. І Ethernet, і Wi-Fi працюють, як правило,
на багатофункціональних пристроях із значним запасом
обчислювальної потужності. З іншого боку, IEEE 802.15.4 був
спроектований щоб обслуговувати різний ринок додатків, де потрібна
велика кількість недорогих малоспоживаючих пристроїв. Пропускна
здатність в цьому стандарті обмежена 250 кбіт/с, а довжина фрейму
обмежена 127 байтами, що гарантує низьку частоту появи помилок
пакетів і бітів при передачі по радіоканалу. Крім того, IEEE 802.15.4
використовує дві адреси: 16-бітну коротку адресу і розширену адресу
EUI-64. Ці адреси зменшують загальний обсяг службової інформації в
заголовку пакета і мінімізують вимоги до пам'яті. Крім того, 6LoWPAN
працює зазвичай в mesh-мережі з ретрансляцією пакетів через кілька
вузлів, що є фундаментальною відмінністю від мережі на основі Ethernet
або Wi-Fi. Нарешті, пристрої, реалізовані на основі 6LoWPAN, як
правило, мають обмежені ресурси, наприклад, оперативну RAM-пам'ять
приблизно 16 кбайт і Flash 128 кбайт.
Внаслідок вищезазначених обмежень ресурсів і
багатострибкової топології 6LoWPAN, підтримка IPv6 поверх мереж
IEEE 802.15.4 створює кілька проблем:
 Датаграми IPv6, природно, непридатні для мереж IEEE
802.15.4. Низька пропускна здатність, обмежена буфеизація і
датаграми, розмір яких дорівнює 1/10 мінімального MTU IPv6, роблять
необхідним стиснення заголовків і фрагментації даних. Наприклад,
заголовки IEEE 802.15.4 можуть обмежити ефективне можливе
 корисне навантаження 81 байтом. У порівнянні з цим заголовки IPv6
(40 байтів), TCP (20 байтів) і UDP (8 байтів) здаються занадто
великими.
 Так як мережі IEEE 802.15.4 мають одночасно і малу
потужність, і низьку пропускну здатність, і, крім того, в якості
середовища передачі використовується радіоканал, вони більш
схильні до відмов і асиметричності каналів (A може чути B, але B НЕ
може чути A). Ці характеристики вимагають, щоб мережевий рівень
був адаптивним і гнучким, і, в той же час, малоспоживаючим і
ефективним.
 Найбільш загальна мережева топологія для 6LoWPAN -
малоспоживаюча комірчаста мережа (low-power mesh network). Це
заперечує припущення, що канальний рівень є єдиним місцем для
широкомовних повідомлень. Цей аспект дуже важливий, так як
зачіпають самі основи IPv6, де засоби виявлення сусідніх вузлів
покладаються саме на цей домен (link domain).
Всі вищезгадані проблеми відносяться і до стандарту 6LoWPAN.

Рівень адаптації 6LoWPAN

При передачі даних за рівнями MAC і PHY завжди
використовується рівень адаптації. Стандарт RFC 2464 визначає, як
пакет IPv6 інкапсулюється у фрейм Ethernet. Це саме можна сказати і
до IEEE 802.11 Wi-Fi. Для 6LoWPAN RFC 6282 визначає, як фрейм
даних IPv6 інкапсулюється поверх радіоканалу IEEE 802.15.4.
 Основна увага робоча група IETF, 6LoWPAN WG, приділяє
оптимізації передачі пакетів IPv6 по малопотужних мережах з втратами
(LLN), таким як IEEE 802.15.4.
Ці умови призвели до публікації документа RFC 6282, який
визначає наступне:
 Стиснення заголовка. 40-байтні IPv6 і 8-байтні заголовки
UDP стискаються з урахуванням використання загальних
областей. Області заголовка ігноруються, якщо вони можуть бути
отримані з канального рівня. Спосіб стиснення заголовків став одним з
факторів, чому прийшли до стандарту, що підтримує тільки IPv6, а не
IPv4. Відзначимо, що немає нічого, що завадило б виконувати TCP в
системі 6LoWPAN, але стиснення заголовка TCP не стало частиною
RFC 6282.
 Фрагментація і повторна збірка. Канал зв'язку IEEE 802.15.4
з максимальною довжиною фрейму 127 байтів не збігається з MTU IPv6,
який становить 1280 байтів. Потрібно відзначити, що формат фрейма
IEEE 802.15.4g не має такого обмеження.
 Бесконтекстние Автоконфігурування - це процес, завдяки
якому пристрої в 6LoWPAN-мережі автоматично генерують власні
адреси IPv6. Є методи, що дозволяють уникнути випадку, коли два
пристрої отримують одну і туж адресу; це називають виявленням
дублювання адреси (DAD).
Ключовим поняттям рівня адаптації 6LoWPAN є Бесконтекстние
або спільно використовується контекстне стиснення з метою
ігнорування областей заголовка. Це дозволяє стискати всі заголовки
(рівня адаптації, мережевого і транспортного рівня) аж до декількох
байтів. Області заголовка можна стискати, так як вони часто мають
загальні значення. Загальні величини виникають через часте
використання підмножини функціональних можливостей IPv6, а саме -
UDP, TCP і ICMP. Можна також зробити припущення щодо спільно
використовуваного контексту, наприклад загального мережевого
префікса для всієї системи 6LoWPAN. Рівень адаптації 6LoWPAN також
видаляє дубльовану інформацію, таку як адреси IPv6 і поле довжини
UDP / IPv6, які можуть бути отримані з інших рівнів.
Стиснення, фрагментація і повторна збірка заголовка
Традиційний спосіб стиснення заголовка IP є базовим і
використовується в з'єднаннях «точка-точка» (point-to-point), де потік
між двома кінцевими точками стійкий. Це стиснення також дуже
ефективно в статичних мережах зі стійкими каналами. Комунікація з
багаторазовими стрибками вимагає стиснення / відновлення даних при
кожному стрибку. Протоколи маршрутизації (наприклад, RPL), зазвичай
працюють в системах 6LoWPAN, забезпечують безліч шляхів доставки
повідомлення одержувачу за рахунок технології прокладки
маршрутів. Це вимагає оновлення інформації про вузли, що істотно
зменшує ефективність стиснення. Для динамічно мінливих мереж з
багаторазовими стрибками і нечастими передачами, наприклад
6LoWPAN-радіомереж, повинен бути застосований інший метод.
три сценарії комунікації:
 Комунікація між двома пристроями в одній і тій же 6LoWPAN-
мережі, яка використовує локальні адреси каналів, заголовок IPv6 при
цьому може бути стиснутий всього до 2 байтів.
 Комунікація в напрямку пристрою за межами 6LoWPAN-
мережі, префікс зовнішньої мережі відомий, тоді заголовок IPv6 може
бути стиснутий до 12 байтів.
 Аналогічно, але префікс зовнішнього пристрою не відомий,
що дає заголовок IPv6 20 байтів.
Кращий випадок в цьому прикладі (перший) не придатний для
передачі прикладних даних (оскільки це може використовуватися тільки
для передачі даних найближчих сусідів), проте здатність стиснення
заголовка при обміні даними між двома сусідніми пристроями особливо
важлива для протоколу маршрутизації. Найгірший випадок (третій) все
ще дає ступінь стиснення 50%. У прикладі передбачається, що ID
інтерфейсу (IID) отримано з MAC-адресу свого пристрою. Потрібно
також зауважити, що стиснення заголовка UDP, як уже сказано вище, є
частиною стандарту 6LoWPAN, що не показано в цьому прикладі.
Щоб допустити передачу фреймів IPv6 поверх радіоканалів IEEE
802.15.4, фрейми IPv6 повинні бути розділені на кілька менших
сегментів. З цією метою в заголовках формуються додаткові дані, щоб
повторно зібрати пакети в правильній послідовності на приймальній
стороні. Коли пакети даних повторно зібрані, додаткова інформація
видаляється і пакети відновлюються в первісному форматі
IPv6. Послідовність фрагментації різна в залежності від того, яка
маршрутизація використовується (різні методи маршрутизації
обговорюються нижче). У разі маршрутизації mesh-under фрагменти
повторно збираються тільки в кінцевій точці призначення, в той час як
у випадку маршрутизації route-over дані повторно збираються при
кожному стрибку. Таким чином, в мережі mesh-under при кожному
стрибку необхідно мати досить великі ресурси для зберігання всіх
фрагментів. Треба взяти до уваги, що в системі mesh-under велика
частина мережевого трафіку формується дуже швидко, так як всі
фрагменти передаються негайно. Якщо які-небудь фрагменти під час
повторного складання (в системі mesh-under) відсутні - повинен бути
повторно переданий повний пакет. Якщо можливо, фрагментації
потрібно уникати максимально довго, так як вона негативно впливає на
термін служби акумулятора пристрою, тому збереження низької
корисного навантаження (включаючи вибір відповідних протоколів
прикладного рівня) і використання стиснення заголовків мають важливе
значення. так як всі фрагменти передаються негайно. Якщо які-небудь
фрагменти під час повторного складання (в системі mesh-under)
відсутні - повинен бути повторно переданий повний пакет. Якщо
можливо, фрагментації потрібно уникати максимально довго, так як
вона негативно впливає на термін служби акумулятора пристрою, тому
збереження низької корисного навантаження (включаючи вибір
відповідних протоколів прикладного рівня) і використання стиснення
заголовків мають важливе значення. так як всі фрагменти передаються
негайно. Якщо які-небудь фрагменти під час повторного складання (в
системі mesh-under) відсутні - повинен бути повторно переданий
повний пакет. Якщо можливо, фрагментації потрібно уникати
максимально довго, так як вона негативно впливає на термін служби
акумулятора пристрою, тому збереження низької корисного
навантаження (включаючи вибір відповідних протоколів прикладного
рівня) і використання стиснення заголовків мають важливе значення.
7.4. Маршрутизація 6LoWPAN
Маршрутизація - функція передачі пакета даних з одного
пристрою на інший, іноді - за допомогою ретрансляції через кілька
проміжних вузлів. Залежно від рівня, на якому розташований механізм
маршрутизації, визначені дві її категорії: mesh-under або route-over
(малюнок 5). Маршрутизація mesh-under використовує дворівневу (до
канального рівня) адресацію (IEEE 802.15.4 MAC або коротку адресу)
щоб передати пакети даних, тоді як маршрутизація route-over
використовує трирівневу (до мережевого рівня) адресацію (IP-адреси)
рис. 7.3.

Джерело Стрибок Одержувач Джерело Стрибок Одержувач

Рис.7.3. Пересилання пакетів mesh-under (два рівні) і route-over

under (три рівні)
 У mesh-мережах 6LoWPAN використовуються дві схеми
маршрутизації:
mesh-under-мережа - в топології з мережею маршрутизація
прозора і передбачає одну IP-підмережу, що представляє один
широкомовний домен. Повідомлення транслюється в одному домені і
відправляється на всі пристрої в мережі, що призводить до високого
мережевого навантаження. Маршрутизація Mesh-переходів буде від
стрибка до стрибка в мережі, але пересилаются тільки пакети до рівня
два (канальний рівень) стека. 802.15.4 обробляє всю маршрутизацію
для кожного стрибка на другому рівні. У такій системі є тільки один IP-
маршрутизатор – граничний.
route-over under (маршрутна) мережа: в топології маршрутизації
мережі будуть стягувати плату переадресації пакетів до рівня 3
(мережевий рівень) стека. Схеми маршрутизації керують маршрутами
на рівні IP. Кожен стрибок являє собою один IP-маршрутизатор.
У route-over-мережах маршрутизація має місце на рівні IP. Таким
чином кожен стрибок в таких мережах представляє один IP-
маршрутизатор. Використання IP-маршрутизації створює передумови
для створення великих потужніших і масштабованих мереж, так як
кожен маршрутизатор повинен реалізувати всі функції, підтримувані
нормальним IP-маршрутизатором. Найбільш широко використовуваним
протоколом маршрутизації в route-over-мережах 6LoWPAN на сьогодні
є RPL (Routing Protocol), як визначено IETF в RFC 6550. У порівнянні з
mesh-under, перевага маршрутизації route-over полягає в тому, що
більшість протоколів, використовуваних сьогодні в стандартному стеці
TCP / IP, може бути реалізовано і використовуватися в незмінному
вигляді.
Автоконфігування і виявлення сусіднього вузла
Автоконфігурування - автономна генерація IPv6-адреси
пристрою. Цей процес для IPv4 і IPv6 істотно різниться. Для IPv6 він
дозволяє пристрою автоматично генерувати свій IPv6-адрес без будь-
якої взаємодії із зовнішнім сервером DHCP або аналогічним
пристроєм. Щоб отримати адресу, хост може зв'язуватися через
протокол виявлення сусідніх вузлів (NDP, neighbor discovery
protocol). Втім, багато хто з функцій NDP також включені в
RPL. Процедура включає чотири типи повідомлень:
 запит в пошуках маршрутизатора (RS, router solicitation);
 оголошення роутера (RА, router advertisiment);
  запит в пошуках сусідніх вузлів (NS, neighbor solicitation);
 оголошення сусіднього вузла (NA, neighbor advertisement).
Виявлення сусіднього вузла IPv6 (ND, network discovery)
дозволяє пристрою виявляти сусідів, підтримувати інформацію про їх
досяжності, конфігурувати маршрути за замовчуванням і поширювати
параметри конфігурації. Повідомлення RS включає, крім іншого,
префікс IPv6-мережі. Всі маршрутизатори в мережі періодично
посилають ці повідомлення. Якщо хост хоче брати участь в 6LoWPAN-
мережі, він призначає собі індивідуальну адресу локального каналу
(FE80 :: IID), потім посилає цю адресу в повідомлення ND всім іншим
учасникам підмережі, щоб перевірити, чи використовується адреса
кимось ще. Якщо хост не почує повідомлення NA за певний період часу
- той припускає, що адреса унікальний. Цю процедуру називають
виявленням дублювання адреси (DAD). Тепер, щоб отримати префікс
мережі, хост посилає повідомлення RS-маршрутизатора, щоб отримати
правильний префікс. Використовуючи ці чотири повідомлення, хост в
змозі призначити собі міжнародний унікальну адресу IPv6.
Використовуючи автоконфігурування адреси джерела, кожен
хост генерує IPv6-адрес локального каналу, використовуючи його
адресу IEEE 802.15.4 EUI-64, 16-бітну коротку адресу або обидві
відразу. У конфігурації mesh-under діапазон адрес локальних каналів
покриває всю 6LoWPAN-мережу, навіть з кількома стрибками, і адрес
локальних каналів достатній для комунікації в 6LoWPAN-
мережі. Єдиний раз, коли необхідно маршрутизації IPv6-адрес - це
передача даних за межі 6LoWPAN-мережі. У конфігурації route-over
досить локальних адрес канального рівня для взаємодії з вузлами в
межах радіопокриття. Маршрутизація адресу потрібна в разі
спілкування з пристроями, віддаленими на кілька стрибків.
Для всіх індивідуальних адрес найефективніше - отримати їх з
локальної адреси IEEE EUI-64. У 6LoWPAN зв'язка між каналом,
адаптацією і IP-заголовком дозволяє ігнорувати і усувати потребу в
визначенні адрес, що призводить до менших заголовків.
Безпека
Безпека необхідна для систем IoT і ця проблема потребує
вирішення. Через природу IoT, чия безліч вузлів у багатьох випадках
має досить обмежені функції, існує багато точок для атаки ззовні. Інший
критичний аспект полягає в тому, що дані, що циркулюють в типовій
системі IoT, це не просто «дані». Інтерес зловмисника до них набагато
вище, так як дані з бездротової системи можуть використовуватися,
наприклад, щоб відкрити двері в ваш будинок або віддалено включити /
вимкнути тривожну сигналізацію.
Сьогодні необхідно використовувати найостанніші схеми
безпеки, щоб бути попереду всіх. 6LoWPAN використовує переваги
потужної системи безпечної передачі даних AES-128 канального рівня,
визначеної в IEEE 802.15.4. Безпека канального рівня забезпечується
автентифікацією і шифруванням. На додаток до безпеки канального
рівня в 6LoWPAN-системах, демонструє відмінну роботу механізм
безпеки транспортного рівня (TLS). TLS, як визначено в RFC 5246,
працює поверх TCP. У разі обмежених ресурсів, де UDP обраний в
якості протоколу транспортного рівня, для забезпечення безпеки на
транспортному рівні може використовуватися RFC 6347 (безпека
датаграмм транспортного рівня). Однак потрібно зазначити, що
реалізація TLS / DTLS вимагає, щоб пристрої мали необхідні
ресурси, такі як апаратний механізм кодування, щоб забезпечити
використання розширеного набору шифрів, і інші.
8. Маршрутизатори та особливості шлюзи
8.1 Функції маршрутизації та шлюзу
8.2. Маршрутизація
8.3. Відмовостійкість і позасмугове управління
8.4. VLAN
8.5. VPN

8.1 Функції маршрутизації та шлюзу

Інтернет речей має, скоріше, галузеву і економічну спрямованість

через кількість пристроїв, які в кінцевому підсумку будуть розгорнуті, і
обсягу даних, які ці пристрої будуть виробляти. Існує два методи щодо
того, як буде формуватися IoT:
 граничні, або крайові, датчики і пристрої забезпечать прямий
шлях до хмари. Це означає, що ці вузли і датчики граничного рівня
матимуть достатньо ресурсів, апаратних засобів, програмного
забезпечення і домовленості про рівень обслуговування для прямої
передачі даних через WAN;
 датчики граничного рівня утворюють групи і кластери
навколо шлюзів і маршрутизаторів для забезпечення проміжних
ділянок, в яких здійснюється перетворення протоколів, обробка даних
на кордонах/в хмарах, а також керування безпекою й автентифікацією
між датчиками і глобальною мережею.
Перша модель є складною і дорогою для потужних і недорогих
датчиків / перетворювачів / пристроїв граничного рівня. Більш логічним
буде другий варіант. Роль граничного маршрутизатора або шлюзу для
датчиків / пристроїв включає в себе формальні мережеві можливості,
які надають сучасні маршрутизатори, такі як маршрутизація каналів,
переадресація портів, тунелювання, безпека і резервування. Принципи
маршрутизації і ретрансляції TCP/IP описані в багатьох джерелах і дуже
широкі для вивчення. У цій темі розглядається роль і необхідність
маршрутизаторів граничного рівня, а також наведено поради та
рекомендації щодо функцій, які слід враховувати при розгортанні
масового рішення IoT.

Функції маршрутизації

В архітектурі IoT маршрутизатор відіграє значну роль в

загальному управлінні, масштабування і безпеки системи. Часто буває,
що роль маршрутизатора спрощується, щоб він діяв просто як шлюз з
одного протоколу в інший (перетворювач стільникового до Bluetooth).
Для комерційного або промислового розгортання необхідно
враховувати набагато більше, особливо коли пристрої знаходяться у
віддалених і рухомих системах.
Функції шлюзу
У попередніх темах ми розглянули кілька типів бездротового
зв'язку, кожен з яких вимагає певної форми передавача і приймача, а
також механізм для перетворення трафіку для підключення до
інтернету. Це найважливіша роль прикордонного шлюзу IoT. Шлюз
перетворює і направляє дані між двома несхожими мережами.
Маршрутизатор може бути шлюзом. Маршрутизатор направляє і керує
трафіком між подібними мережами. В архітектурі IoT може бути
встановлена суміш 6LoWPAN, яка адресується по IPv6, обмінюючись
інформацією з зовнішнім світом через пристрій, який діє як шлюз, що
з'єднує протоколи 802.15.4 з фізичним транспортом Wi-Fi або 802.3, але
також направляючи і маршрутизуючи дані з використанням IP - рівня,
яке поділяється між інтернетом і mesh-мережею 6LoWPAN. Часто
прикордонний шлюз також є центральним контролером PAN. Це
означає, що всі функції управління мережею PAN, забезпечення
безпеки, автентифікація і надання нових вузлів, даних щодо управління
та пристроїв управління живленням відносяться до відповідальності
прикордонного шлюзу.

8.2. Маршрутизація
Основна функція маршрутизатора - це забезпечення з'єднань
між сегментами мережі. Маршрутизація вважається функцією третього
рівня стандартної моделі OSI, оскільки вона використовує рівень IP-
адресації для управління передачею пакетів. По суті, всі
маршрутизатори покладаються на таблицю маршрутизації для
управління потоком даних. Таблиця маршрутизації використовується
для пошуку найкращого маршруту за IP-адресою призначення пакета.
Існує кілька перевірених алгоритмів, використовуваних для
ефективної маршрутизації. Одним типом маршрутизації є динамічна
маршрутизація, де алгоритми реагують на зміни в мережі і топології.
Інформація про стан мережі поширюється протоколом маршрутизації
за часом або по тому, що сталося оновленню. Прикладами динамічної
маршрутизації є маршрутизація вектора відстані і маршрутизація стану
каналу.
В якості альтернативи статична маршрутизація важлива і
корисна для невеликих мереж, яким потрібні певні шляхи, налаштовані
між маршрутизаторами. Статичні маршрути неадаптивні, тому немає
необхідності сканувати топологію або оновлювати метрики. Вони
передбачені на маршрутизаторі:
 маршрутизація по найкоротшому шляху - побудова графа, що
представляє маршрутизатори в мережі. Дуга між вузлами представляє
собою відомий зв'язок або з'єднання. Алгоритм просто знаходить
найкоротший шлях з будь-якого джерела до будь-якого пункту
призначення;
 лавинна маршрутизація - кожен пакет повторюється і
транслюється кожним маршрутизатором в кожну кінцеву точку його
зв'язків. Це генерує величезну кількість дублюючих пакетів і вимагає,
щоб в заголовку пакета був встановлений лічильник переходів, щоб
гарантувати, що пакети мають обмежений час життя. Альтернативою є
вибіркова розсилка, яка наповнює мережу тільки в основному напрямку
пункту призначення. Лавинні мережі є основою мереж Bluetooth;
 маршрутизація на основі потоку - перевіряє поточний потік в
мережі до визначення шляху. Для будь-якого даного з'єднання, якщо
відомі пропускна здатність і середній потік, обчислюється середня
затримка пакета по цьому з'єднанню. Цей алгоритм знаходить
мінімальне середнє значення;
 маршрутизація на основі вектора відстані - таблиця
маршрутизаторів містить найвідомішу відстань до кожного пункту
призначення. Таблиці оновлюються сусідніми маршрутизаторами.
Таблиця містить запис для кожного маршрутизатора в підмережі. Кожен
запис містить кращий маршрут/шлях і приблизну очікувану відстань до
пункту призначення. Відстань може бути метрикою кількості переходів,
затримки або довжини черги;
 маршрутизація за станом каналу - маршрутизатор
спочатку виявляє всіх своїх сусідів за допомогою спеціального пакета
HELLO. Маршрутизатор вимірює затримку для кожного зі своїх сусідів
шляхом відправки пакета ECHO. Ця інформація про топологію і час ділі
розсилається всім маршрутизаторам в підмережі. Повна топологія
будується і публікується всіма маршрутизаторами;
 ієрархічна маршрутизація - маршрутизатори розділені на
регіони і мають ієрархічну топологію. Кожен маршрутизатор підтримує
розуміння свого регіону, але не всієї підмережі. Ієрархічна
маршрутизація також є ефективним засобом управління розміром
таблиці маршрутизації і ресурсами в обмежених пристроях;
 широкомовна маршрутизація - кожен пакет містить список
адрес призначення. Широкомовний маршрутизатор досліджує адреси і
визначає набір вихідних ліній для передачі пакета. Маршрутизатор
буде генерувати новий пакет для кожної вихідної лінії і включати тільки
адресати, необхідні для цього новосформованого пакета;
 маршрутизація за допомогою багатоадресної розсилки:
мережа розділена на чітко визначені групи. Додаток може відправляти
пакет всій групі, а не одному адресату або на широкомовну адресу.
Типові граничні маршрутизатори будуть підтримувати такі
протоколи маршрутизації, як Border Gateway Protocol (BGP), Open
Shortest Path First (OSPF), Routing Information Protocol (RIP)
і RIPng.
Фахівець, який використовує граничні маршрутизатори в
реальній роботі, повинен знати про особливості використання
протоколу маршрутизації в порівнянні з іншими, особливо якщо
з'єднання між маршрутизаторами є WAN-з'єднанням з обмеженням
даних:
 BGP - BGP-4 є стандартом для протоколів інтернет-доменної
маршрутизації і описаний в RFC 1771; він використовується більшістю
інтернет-провайдерів. BGP - це алгоритм динамічної маршрутизації на
основі вектора відстані, він рекламує цілі шляхи в повідомленнях
оновлень маршрутизації. Якщо таблиці маршрутизації є великими, це
вимагає значної пропускної здатності. BGP відправляє 19-байтовое
повідомлення keepalive кожні 60 с для підтримки з'єднання. BGP може
бути слабким протоколом маршрутизації для топології mesh-мережі,
оскільки BGP підтримує з'єднання з сусідами. BGP також страждає від
зростання таблиць маршрутизації в великих топологіях. BGP також
унікальний, так як це один з єдиних протоколів маршрутизації на основі
TCP-пакетів;
 OSPF - цей протокол описаний в RFC 2328, він забезпечує
переваги масштабування мережі і збіжності. Інтернет-магістраль і
корпоративні мережі інтенсивно використовують OSPF. OSPF - це
алгоритм стану з'єднання, який підтримує IPv4 та IPV6 (RFC 5340) і
працює з IP-пакетами. Перевага полягає в виявленні за секунди
динамічних змін з'єднань і реагуванні;
 RIP - друга версія RIP є алгоритм маршрутизації вектора відстані,
заснований на підрахунку переходів з використанням протоколу
внутрішнього шлюзу. Спочатку заснований на алгоритмі Беллмана-
Форда, тепер він підтримує підмережі, які змінюють свої розміри,
долаючи обмеження вихідної версії. Петлі в таблиці маршрутизації
обмежені завданням максимальної кількості переходів в дорозі (15).
RIP працює по UDP і підтримує тільки трафік IPv4. RIP має більш
тривалий час збіжності, ніж такі протоколи, як OSPF, але його легко
адмініструвати для топологій невеликого граничного маршрутизатора.
Проте, збіжність для RIP з усього декількома маршрутизаторами може
зайняти кілька хвилин;
 RIPng - RIPng означає RIP наступного покоління (RFC 2080). Він
дозволяє підтримувати трафік IPv6 і IPsec для автентифікації. Типова
таблиця маршрутизації, яка використовується у виробничому
середовищі таким маршрутизатором, як Cradlepoint IBR900, виглядає
наступним чином:

У цьому прикладі є три таблиці: wan, main і local.

Кожна таблиця містить конкретні шляхи маршрутизації,
характерні для цього інтерфейсу:
Destination - повний або частковий IP-адрес призначення
пакета. Якщо таблиця містить IP, вона буде посилатися на решту
запису, щоб дозволити інтерфейс для маршрутизації на часткову
адресу; може бути задана з префіксом /. Це вказує фіксовані позиції
бітів адреси для дозволу. Наприклад, /24 в 192.168.1.0/24 вказує, що
старші 24 біта 192.168.1 є фіксованими, а молодші 8 біт можуть мати
будь-яку адресу в підмережі 192.168.1. *;
Gateway - це інтерфейс для направлення пакетів, відповідний
знайденому адресату. У попередньому випадку шлюз вказаний як
96.19.152.1, а пункт призначення - default. Це означає, що вихідна WAN-
адреса 96.19.152.1 буде використовуватися для всіх адрес
призначення. Це, по суті, пересилання IP;
Device UID - це буквено-цифровий ідентифікатор інтерфейсу для
відправки даних. Наприклад, будь-яке місце призначення в підмережі
172.19.152.0/21 направить пакети в інтерфейс під назвою iface: pertino0.
Часто це поле буде виражатися цифровю IP-адресою, а не
символічним посиланням;
Flags - використовується для діагностики і вказівки стану
маршруту. Стани можуть бути «маршрут працює, використовувати
шлюз»;
Metric - це відстань до місця призначення, зазвичай
підраховується за кількістю переходів;
Type - можуть використовуватися кілька типів маршрутів:
- unicast: маршрут є реальним шляхом до місця призначення;
- unreachable: мета недоступна. Пакети відкидаються, і генерується
повідомлення ICMP, яке вказує, що хост недоступний. Місцевий
відправник отримує помилку EHOSTUNREACH;
- blackhole: одержувачі недосяжні. На відміну від типів «prohibit»,
пакети будуть тихо відкинуті. Локальні відправники отримують помилку
EINVAL;
- prohibit: одержувачі недосяжні. Пакети будуть відкидатися і
генеруються ICMP-повідомлення. Локальні відправники отримують
помилку EACCES;
- local: одержувачем є цей хост. Пакети загортаються назад і
доставляються локально;
- broadcast: пакети будуть передаватися як широкомовні через
інтерфейс до всіх получателям4
- throw: спеціальний маршрут управління, щоб насильно відкинути
пакети і згенерувати повідомлення ICMP про недоступність. У
наведеному вище прикладі слід зазначити, що адреси IPv6 змішуються
з адресами IPv4. Наприклад, 2001: 470: 813b :: / 48 в основній таблиці -
адреса IPv6 с / 48-бітної підмережею.

8.3. Відмовостійкість і позасмугове управління

Відмовостійкість критична для деяких граничних

маршрутизаторів IoT, особливо для додатків для транспортних засобів
і по догляду за пацієнтами.
Відмовостійкість - це переключення з одного інтерфейсу WAN
на інший, коли основне джерело втрачено. Втрата WAN може бути
пов'язана з втратою стільникового зв'язку в тунелі. Компанії-
перевізнику з автопарком пересувних холодильних камер може
знадобитися гарантоване підключення, при тому що послуги
стільникового зв'язку змінюються по всій країні. Перехід від одного
стільникового оператора до іншого з використанням декількох
ідентифікаторів SIM-карт може допомогти пом'якшити і згладити
перепідключення. Іншим варіантом може бути використання
клієнтського Wi-Fi в якості основного інтерфейсу WAN для внутрішнього
моніторингу стану, але підключення до стільникового WAN заради
відмовостійкості, якщо сигнал Wi-Fi втрачений. Відмовостійкість
повинна бути безболісною і автоматичною без втрати пакетів або
помітного впливу на затримку даних.
Позасмугове управління є актуальним для пристроїв IoT,
зокрема у відмовостійких умовах, коли для управління обладнанням
необхідний виділений чи ізольований канал. Іноді це називається
управлінням лампочками (LOM), якщо первинні системи вийшли з ладу,
пошкоджені або мають втрату потужності; як і раніше можливо
управляти і перевіряти обладнання віддалено через канал бічної смуги.
У IoT це може бути корисно для ситуацій, що вимагають гарантованого
часу безвідмовної роботи і дистанційного керування, таких як
моніторинг нафти і газу або промислова автоматизація. Добре
продумана система позасмугового управління не повинна мати
ніякого відношення до контрольованої системи для свого
функціонування. Позасмугове управління повинне бути додатковим і
ізольованим від системи, як показано на рис. 8.1.

Рис. 8.1.Приклад конфігурації для позасмугового управління

 8.4. VLAN
VLAN функціонує, як будь-яка інша фізична локальна мережа,
але дозволяє групувати комп'ютери і інші пристрої, навіть якщо вони
фізично не прив'язані до одного мережного комутатора. Поділ
відбувається на рівні лінії передачі даних (другий рівень) моделі OSI.
VLAN - це форма мережевої сегментації пристроїв, додатків або
користувачів, хоча вони знаходяться в одній і тій же фізичній мережі.
VLAN також може групувати хости разом, хоча вони не знаходяться на
одному мережевому комутаторі, що істотно полегшує розбиття на
мережі без використання додаткових кабелів. Стандарт IEEE 802.1Q -
це стандарт, за яким побудовані VLAN. По суті, VLAN використовує
ідентифікатор або тег, що складається з 12 біт в кадрі Ethernet. Таким
чином, існує жорстке обмеження в 4096 потенційних VLAN в одній
фізичній мережі. Комутатор може призначити порт для безпосередньої
прив'язки до певної VLAN. Оскільки VLAN працює на другому рівні
стека, трафік може тунелюватись через третій рівень, що дозволяє
географічно розділеним VLAN використовувати загальну топологію
(рис. 8.2). Вище показана корпоративна точка продажу (POS) і система
VoIP (IP-телефонія), яка фактично ізольована від набору пристроїв IoT,
а також гостьового Wi-Fi. Це робиться за допомогою адресації VLAN,
хоча система використовує одну і ту ж фізичну мережу. Тут ми
припускаємо, що це інтелектуальне рішення IoT, де все граничні
пристрої і датчики IoT підтримують IP-стек і адресуються через
локальну мережу.
Дизайн VLAN особливо корисний в світі IoT. Ізолювання пристроїв IoT
від інших корпоративних функцій є типовим сценарієм. VLAN корисні
тільки при роботі з пристроями, що підтримують IP-адресацію.
 Рис. Приклад архітектури VLAN в сценарії філій або роздрібної
торгівлі

8.5. VPN
VPN-тунелі використовуються для встановлення безпечного
підключення до віддаленої мережі через публічну мережу. Наприклад,
VPN-тунелі можуть використовуватися через інтернет для окремого
користувача для підключення до захищеної корпоративної мережі під
час поїздок або для з'єднання двох офісних мереж для роботи в якості
однієї мережі. Дві мережі налаштовують безпечне з'єднання через
(зазвичай) незахищений інтернет, застосовуючи протоколи
шифрування VPN.
Для впровадження IoT для передачі даних з віддалених датчиків
і периферійних пристроїв в корпоративну або приватну локальну
мережу необхідно VPN. Як правило, корпорація буде знаходитися за
брандмауером, а VPN - це єдиний спосіб переміщення даних
безпосередньо на приватний локальний сервер. У цих випадках VPN
може Існує кілька VPN:
Internet Protocol Security (IPSec) VPN - традиційна технологія VPN,
яка знаходиться на мережевому рівні стека OSI і забезпечує передачу
даних через тунель між двома кінцевими точками;
OpenVPN - це VPN з відкритим вихідним кодом для безпечного
з'єднання «точка-точка» і «місце-місце» в маршрутизованих або
мостових конфігураціях. Вона включає спеціальний протокол безпеки,
що використовує SSL/TLS (OpenSSL) для обміну ключами та
управління шифруванням і обміну даними. Вона може працювати через
транспорти UDP і TCP. SSL поширений в більшості додатків для
браузерів, тому SSL VPN-системи можуть забезпечувати захищені
тунелі на для додатків, а не всієї мережі;
Generic Routing Encapsulation (GRE) - створює з'єднання «точка-
точка» між кінцевими точками через тунель, аналогічний тунелю VPN,
але інкапсулює його корисне навантаження. Він обгортає внутрішній
пакет у зовнішній пакет. Це дозволяє передавати дані корисного
навантаження через інші IP-маршрутизатори та тунелі незміненими.
Крім того, тунелі GRE можуть транспортувати IPV6 і багатоадресні
передачі;
Layer 2 Tunneling Protocol (L2TP) - створює з'єднання між двома
приватними мережами через дейтаграми UDP, типово
використовуються для VPN або як частина служб доставки
провайдерами. У протоколі немає вбудованої безпеки або
шифрування, і для цього часто використовується IPsec. VPN повинен
або довіряти базовим мережевим протоколам, або забезпечувати
власну безпеку.
VPN-тунелі зазвичай використовують IPsec для автентифікації та
шифрування пакетів, переданих по тунелях. Щоб налаштувати
тунельний маршрутизатор VPN на одному кінці, має бути інший
пристрій (зазвичай це маршрутизатор), який також підтримує IPsec на
іншому кінці. Internet Key Exchange (IKE) - це протокол безпеки в IPsec.
IKE має дві фази. Перша фаза відповідає за встановлення
безпечного каналу зв'язку, а на другому етапі встановлений канал
використовується партнерами IKE. Маршрутизатор має кілька різних
параметрів протоколу безпеки для кожної фази, але вибір за
замовчуванням буде достатнім для більшості користувачів. Кожен
обмін IKE використовує один алгоритм шифрування, одну хеш-функцію
і одну групу DH для безпечного обміну:
Encryption - використовується для шифрування повідомлень,
відправлених і отриманих через IPsec. Типові стандарти і алгоритми
шифрування включають AES 128, AES 256, DES і 3DES;
Hash - використовується для порівняння, автентифікації і
перевірки даних по VPN, забезпечення того, що вони приходять в
правильній формі, і для отримання ключів, використовуваних IPSec.
Типові функції хешу, які слід очікувати в маршрутизаторі
корпоративного рівня, включають MD5, SHA1, SHA2 256, SHA2 384 і
SHA2 512. Зверніть увагу, що деякі комбінації шифрування / хешу (такі
як 3DES з SHA2 384/512) є дорогими при обчисленні, що впливає на
продуктивність WAN. AES забезпечує хороше шифрування і працює
набагато швидше, ніж 3DES;
групи DH: група DH (Diffie-Hellman) є властивістю IKE і
використовується для визначення довжини простих чисел, пов'язаних з
генерацією ключів. Надійність генерується ключа частково
визначається надійністю групи DH. Група 5, наприклад, має більшу
міцність, ніж група 2: - група 1: 768-бітний ключ;
- група 2: 1024-бітний ключ;
- група 5: 1536-бітний ключ.
У першій фазі IKE ви можете вибрати одну групу DH, тільки якщо
використовуєте агресивний режим обміну. Алгоритми перераховані в
порядку пріоритету. Ви можете змінити порядок цього списку
пріоритетів, клацнувши та перетягнувши алгоритми вгору або вниз.
Будь-який вибраний алгоритм може використовуватися для IKE, але
алгоритми у верхній частині списку, ймовірно, будуть
використовуватися частіше.