Speaker A
Так. Ну добре. Значить, що в нас було на минулій лекції? Ми з вами почали е-е тему протоколів, які застосовуються в інтернеті речей і в принципі сказали, що м можна розглядати протоколи на різних рівнях.
Лекція про протоколи передачі даних у IoT, з акцентом на MQTT та порівняння з HTTP для хмарних технологій.
Key Takeaways
- MQTT є оптимальним протоколом для передачі даних у IoT завдяки низьким накладним витратам.
- HTTP, хоч і широко використовується, не завжди підходить для ресурсно обмежених IoT пристроїв.
- Архітектура MQTT базується на брокері, який централізовано керує повідомленнями між видавцями та підписниками.
- Використання шлюзу дозволяє поєднувати внутрішні протоколи пристроїв з хмарними сервісами через HTTP.
- Для IoT характерна велика кількість маленьких повідомлень, що робить ефективність протоколу ключовою.
Summary
- Огляд протоколів передачі даних в Інтернеті речей на прикладному рівні.
- Пояснення концепції MQTT як message oriented middleware з брокером, видавцями та підписниками.
- Порівняння MQTT з HTTP, з акцентом на ефективність та накладні витрати.
- Опис архітектури REST та використання HTTP-запитів (GET, POST, PUT, DELETE).
- Переваги та недоліки HTTP у контексті IoT пристроїв, особливо через обмежені ресурси.
- Роль шлюзу як перекладача між внутрішніми протоколами пристроїв та HTTP для хмари.
- Пояснення структури URI та її ролі у REST-архітектурі.
- Пояснення процесу встановлення з’єднання, публікації та підписки в MQTT.
- Вказівка на те, що MQTT має в 5-6 разів менші накладні витрати порівняно з HTTP.
- Значення MQTT для ефективної передачі невеликих, але численних даних від сенсорів.
Full Transcript — Download SRT & Markdown
Speaker A
Якщо брати прикладний рівень, то одним з дуже популярних протоколів, що застосовується в інтернеті речей, є MQTT.
Speaker A
Е-е, в принципі, MQTT в основному використовується як протокол, е-е, значить, який в якому дані передаються від граничних пристроїв сенсорної мережі.
Speaker A
далі у транспортну мережу, далі у хмару, скажімо так. Ее, ну, тобто яка ситуація? Ми з вами розглядали ее сенсорні мережі, ми з вами розглядали персональні мережі ее в інтернеті і говорили, що там є свої технології зв'язку, свої способи
Speaker A
взаємодії. Вони собі там варяться в своїх технологіях, можна сказати. Але інтернет речей тим і відрізняється від просто систем міжмашинної взаємодії, наприклад, що йому треба виходити назовні.
Speaker A
Ну, а ззовні у нас, як правило, використовується TCPIP. Ну, хоча це не обов'язково, а не всі глобальні мережі, вони на TCPIP працюють, але інтернет, він використовує TCP.
Speaker A
І тому взагалі е виникає питання, а в якому власне форматі, на прикладному рівні передавати дані.
Speaker A
Ее от ті дані, що, наприклад, були взяті із датчиків. От. І нам треба їх, наприклад, десь у хмару надіслати, щоб потім обробити.
Speaker A
Так секундочку. Так значить да перепрошую ми продовжуємо. Значить, ми сказали, що на прикладному рівні треба дані якось паковувати, якось передавати.
Speaker A
Так, да. Ну і одним з популярних протоколів є MQTT. який використовує концепцію, ее, яка називається Message Oriented MLV. Значить, ее це концепція, коли проміжне програмне забезпечення орієнтується на повідомлення. Значить, message oriented midle.
Speaker A
Ідея тут в тому, що пристрої не обмінюються даними між собою напряму. А роблять це через спеціальні черги повідомлень, ну і якими зазвичай займається спеціальний пристрій. Тут він називається брокер.
Speaker A
Е, тобто одні пристрої виступають як виробники даних. Ее вони тут називаються видавцями. Вони надсилають повідомлення до брокера і той їх, як правило, накопичує у спеціальному сховищі своєму. Ну, часто це називається чергою, хоча б MQTT - це не класична черга. А інші учасники - це
Speaker A
споживачі цих даних, які отримують їх у вигляді повідомлень. Тут вони називаються підписниками. А взагалі це називається концепція message m Так, зараз секундочку, щоб заважало вимкнути.
Speaker A
Так. Да, ну, ми тут сказали, що в принципі в принципі, якщо ми виходимо на зовнішню мережу, ми могли б використовувати HTTP, але скажімо так, скажімо так, це не дуже вдалий варіант.
Speaker A
Ну по-перше ну, з одного боку, з одного боку класичний клієнтсерверний варіант, який використовує HTTP, часто це архітектура, так звана RESTF архітектура, передбачає, що є сервер, який зберігає стани ресурсів, є клієнти, які до нього звертаються, і взаємодія відбувається через стандартні HTTP запити, такі як
Speaker A
get, post, put, delete. В цьому випадку брокер нам не потрібний. Клієнт безпосередньо звертається до сервера.
Speaker A
Е-е, ну, перевагами такого підходу є те, що ми можемо використовувати захищене з'єднання HTTPS. Зазвичай зараз всі сайти через цей протокол працюють. М, але така модель, вона взагалі передбачає, ну, е, синхронність для клієнта. Тобто клієнт, він, ну, знає, в
Speaker A
який момент він зробить запит. Е-е, відповідальність відповідно за обробку помилок також лягає на клієнта. Задача сервера очікувати, коли до нього звернутися і відповісти.
Speaker A
А ще одним важливим елементом, який використовується у архітектурі REST - це використання універсальних ідентифікаторів ресурсу URI. Тобто це адреси, за якими доступні ресурси у мережі. Ну, всім нам знайомі URL адреси, да, значить, доменні імена, е, плюс, ну, певна структура. Це один з видів якраз
Speaker A
ось цих універсальних ідентифікаторів ресурсу. Тобто там спочатку в нас HTTP2 сле, тобто що вказує, що ми будемо використовувати протокол HTTP, потім доменне ім'я, потім може порт вказуватися, потім шлях всередині вже веб-сервера і там далі додаткові параметри запиту. Така, ну, знайома вам
Speaker A
схема. А, значить, ну і в принципі цей варіант, він вже відпрацьований давно, він добре працює в інтернеті багато років, а, але для інтернету речей він не завжди підходить. От ми на першій лабораторній роботі дивилися, що можна побудувати, е, систему там розумного
Speaker A
дому з виходом на інтернет на основі традиційних е-е інтернет-технологій, веб-технологій. Е, ну от що стосується саме HTTP, ее для того щоб ми могли по HTTP звертатися, да, до хмарних е-е якихось серверів, служб, треба, щоб, м, були пристрої, які реалізують весь цей
Speaker A
стек та весь цей протокол. Ну, весь протокол HTP, він доволі складний, особливо якщо йдеться про захищену реалізацію, да, і щеps. І, ну, для пристроїв це взагалі не варіант. Тобто IT- пристрої, вони слабкі за ресурсами, як ми знаємо. Вони працюють від батарей
Speaker A
часто тому скажімо так, на пристроях HTTP ее клієнт або сервер не часто реалізують на пристроях інтернету речей. Можливий варіант зі шлюзом, який буде постійно в якості перекладача працювати. Тобто між собою пристрої м-м обмінюються даними в одному форматі, за одним протоколом, а далі вже
Speaker A
йдесь агрегація цих даних на шлюзі і далі він там вже по HTTP направляє у хмару.
Speaker A
Такий, в принципі, варіант можливий. Хоча і тут треба сказати, що дані, що поступили з датчиків, вони будуть, ну досить досить сильно обростати ось цими HTTP заголовками і так далі. Він неоптимізований підрозділ. Е, тому і власне виникла ідея, е, щоб використати спеціальний протокол,
Speaker A
який би мав низку переваг перед HTTP. І от ми тут якраз і бачимо, що е-е MQTT, якщо його порівнювати за е-е обсягом даних, що передаються при читанні і записі блоків даних, він якраз демонструє в п'ять-ші разів менші накладні витрати на свою роботу. Тобто
Speaker A
це його перевага, тому що е-е в принципі в інтернеті речей характерна така ситуація, що в нас е-е даних багато, але вони маленькі за розміром. Тобто, ну, наприклад, кожне вимірювання з датчика, воно само по собі маленьке, але оскільки датчиків може бути багато, значить,
Speaker A
відповідно виникає великий обсяг даних. І ось ці всі дані, ну, якщо вони всі будуть упаковуватися в HTTP, да, там будуть дуже великі накладні витрати.
Speaker A
Звісно, що якщо ви використовуєте розумний шлюз, то він буде якось упаковувати все це діло і тоді накладні витрати зменшиться. Але все одно MQTT став дуже популярним варіантом, дуже популярною заміною HTTP в інтернеті речей. Тому давайте розглянемо його більш докладно. Значить, ось тут в нас
Speaker A
показана концепція Message Oriented midlev, яку ми, в принципі, м обговорили і тільки що ми бачили на іншому слайді подібну схему. Тут просто додатково показано, що воно все на повідомленнях ее побудовано.
Speaker A
Справа у нас тут архітектура Restful, яка в HTTP використовується, ну, передбачає використання HTTP, да.
Speaker A
Ее, і тут в нас запит-відповідь. Запит відповідь. Тут має бути сервер, здається, да? Тут має бути сервер. Тут клієнт.
Speaker A
А от у нас сервіс message oriented medvя. Значить, брокер якраз реалізує цей сервер. Є видавці, є підписники.
Speaker A
видавець спочатку з'єднується з сервісом message для того, щоб потім публікувати дані. Тобто в нас є повідомлення типу Connect, він встановлює з'єднання.
Speaker A
От очікує підтвердження цього з'єднання. Потім в рамках цього встановленого з'єднання він публікує дані. Причому публікує їх у певних темах. Те, що називається топік. Ми бачили, да, в лабораторній роботі номер три. І тут в нас є ще data, тобто це таке корисне
Speaker A
навантаження, що називається, тобто фактичні, наприклад, дані здавчики. От і сервер, сервіс брокер. Значить, він якраз нам підтверджує кожен раз, коли ми публікуємо дані, він підтверджує, що ці дані отримані.
Speaker A
От. А є підписники з іншого боку, да, які також встановлюють з'єднання, також отримують підтвердження про це. Це з'єднання потім висить е-е робоче.
Speaker A
Далі вони підписуються subscribe, да, підписуються на певні теми. І в принципі вони е-е да, значить, далі вони переходять, можна сказати, в режим очікування, тобто вони очікують, коли брокер буде публікувати вже їм.
Speaker A
Тобто, коли до нас поступила до брокера поступила нова порція даних з видавця, він через деякий невеликий час буде транслювати ці дані до усіх підписників, що підписалися на цю тему, на цей топік.
Speaker A
Ось така концепція. Значить, ну і, до речі, за такою концепцією працюють не тільки працює не тільки MQTT, є інші протоколи також AMQP, наприклад, е, STМП протокол є такий. Вони також використовують цю концепцію. Важливою особливістю такої концепції є надійність її роботи. Тобто,
Speaker A
ее, повідомлення можуть зберігатися в черзі цього брокера, навіть тоді, коли, е, частина системи, інша частина системи тимчасово недоступна. Ну, ми будемо ще про це говорити. Тобто завдяки тому, що в нас рознесені в часі ці операції взаємодії між видавцем і підписником, в
Speaker A
нас такі системи є більш стійкими до збоїв і вони добре підходять якраз для розподілених айотрішень, де такі збої часто відбуваються. Тобто брокер виступає таким собі посередником, який таким собі буфером, який акумулює е тимчасові втрати зв'язку з видавцями і підписниками.
Speaker A
Тобто він може почекати, наприклад, поки підписник з'явиться на зв'язку. От. Ну і буває таке, що видавці пропадають зі зв'язку. Навіть нерідко таке буває, тому що видавці - це якісь датчики, як правило.
Speaker A
Да. До речі, е технологія, з якої виріс сам по собі протокол MQTT, має цікаву історію. Ще в 93му році в компанії IBM була створена система websfare message QA, яка призначалася для забезпечення надійного обміну даних між розподіленими системами.
Speaker A
Ну, а пізніше, в 99му році двоє інженерів Стнфорд, Клар та Ніппер розробили на основі цієї технології новий протокол, створили його під конкретну задачу передачі даних з нафто і газопроводів через нестабільні канали зв'язку, такі, наприклад, як супутниковий зв'язок. І
Speaker A
ось вони назвали цей протокол MQTT. Значить, вимоги були в них які, щоб про щоб з одного боку він мав просту реалізацію, щоб він працював ефективно при низькій пропускній здатності, підтримував певний рівень недійності доставки, те, що називається Quality of
Speaker A
Service, був незалежним від платформи, відстежував стан з'єднання з, е, учасниками взаємодії. і при цьому забезпечував базові механізми безпеки ще й додатково, тобто ціла низка таких викликів. І от їм вдалося реалізувати протокол MQTT з урахуванням усіх цих вимог.
Speaker A
Тобто ми бачимо, що вони розраховували не на стабільні лінії зв'язку, а якраз на ее такі невеликі пропускні здатності і з можливими втратами зв'язку. вийшов легкий економний протокол обміну повідомленнями добре, який добре працює там, де в нас обмежені ресурси, слабкі
Speaker A
пристрої, нестабільні мережі, велика затримка або вузькі канали зв'язку. А протокол був спеціально оптимізований так, щоб мінімізувати навантаження на мережу пристроїв, але при цьому забезпечив достатню надійність передачі даних.
Speaker A
Він став дуже популярним у системах міжмашиної взаємодії взагалі, ну і в інтернеті речей у зокрема.
Speaker A
Також у мобільних застосунках він використовується, де важливі економія трафіку і заряду батарей. Е, спочатку цей протокол був внутрішньою розробкою IBM. Він не був відкритим стандартом, але в 2010 році з'явилася його відкрита версія. Тобто IBM вирішив відкрити специфікації. Версія була 3.1. І е-е
Speaker A
значить, до речі, він був стандартизований ще до м Ну да, значить, він був стандартизований у 2013 році консорціум Oasis, а в 2014 опублікований як відкритий стандартом QTT 311.
Speaker A
Також він отримав статус міжнародного стандарту ІОК 20922. У 2019 році була опублікована остання на сьогодні версія MQTT 5.0 із розширеними можливостями, серед яких краща обробка помилок, додаткові властивості повідомлень, керування сесіями, ну і так далі.
Speaker A
Так значить ну да, тут ось у нас перелік особливостей протоколу MQTTT по моделі видання підписка. В принципі, ми вже сказали, що в нас тут є А-а, до речі, до речі, ця модель іноді називається Pub. Значить, ну, Пап - це
Speaker A
той, хто публікує, Sub - це той, хто підписується. Subscribe. Е-е, значить, пабліше, значить, видавці. Хто у нас тут видавці? Ну, у нас тут ми що бачимо, що у нас тут є брокер. Як правило, він знаходиться в хмарі.
Speaker A
От. Ее, тобто часто функції брокера надає провайдер хмарних послуг. Ну, це не обов'язково. Наж в нас може бути ізольований окремий MQTT брокер. От.
Speaker A
А далі навколо нього багато-багато підсистем, різних систем інтернету речей. От у нас, наприклад, є, що у нас тут є? Температурний Bluetooth датчик, є розумний датчик вологості, є мобільний застосунок клієнта.
Speaker A
От всі вони мають якось підтримувати взаємодію по MQTT. Ну от, наприклад, температурний Bluetooth датчик, він сам по собі простий. Для того, щоб він міг передати дані по MQTT, е-е, треба, щоб був якийсь там кройовий маршрутизатор на границі цієї м сенсорної мережі, та який
Speaker A
вміє реалізовувати функції, значить, клієнта MQTT, а саме в даному випадку видавця. Видавця повідомить. Тобто датчик видає дані, вони оформлюються в MQTT і далі публікуються на брокері.
Speaker A
Ну, а розумний датчик вологості в даному випадку має вбудований клієнт MQTT. Тобто він може напряму без використання додаткових там маршрутизаторів або якихось проміжних сервісів публікувати дані на тому самому брокері.
Speaker A
Ее, тобто він може, скажімо так, не займатися ось всім, що пов'язано з HTTP, да, а працювати лише на протоколі MQDT.
Speaker A
Далі. Далі. Ну, ось ми тут бачимо, що тут, значить, в нас стрілки пабліш ідуть до провайдераних послуг, до брокера.
Speaker A
І тут є дві гілки: температура, вологість. А далі є підписники, яких цікавить ця інформація. Значить, ну, наприклад, привід системи вентиляції.
Speaker A
Е, привід системи вентиляції з бездротовим екран індикатором. Така собі підсистема управління і моніторингу, да?
Speaker A
Е-е, вона зацікавлена в тому, щоб отримати інформацію, наприклад, про е-е вологість. Тому вона підписується.
Speaker A
Значить, в нас тут чорна стрілка. підписується на повідомлення в темі вологість і брокер буде їй відповідати, публікувати дані, отримані від розумного датчика вологості. Та є далі якийсь, да, ну, тут також він нерозумний, він працює через крайовий маршрутизатор клієнта, як і ось
Speaker A
цей температурний датчик. Менеджер операційних технологій з клієнтською панеллю. Вона тут на базі комп'ютера, вона сама реалізує функції клієнта MQTT.
Speaker A
Її цікавить і те, і інше. Тобто вона підписується і на температуру, і на вологість, і отримує відповідно і те, інше. Ну, а от мобільний застосунок клієнта, наприклад, там е-е його цікавить температура саме тому він підписується на температуру.
Speaker A
Так, да. Значить, ми говорили, що важливою особливістю такої моделі є розв'язування у просторі і часі. Ну, по-перше, пристрої не прив'язані один до одного фізично, тобто температурний датчик, е-е, е-е, мобільний застосунок, вони рознесені, е, і підписник може отримувати і
Speaker A
обробляти дані не одразу, а пізніше. Тобто, що важливо для інтернету речей, де пристрої можуть бути тимчасово недоступними, мати обмежений канал зв'язку і за рахунок цього періодично лише з з'являтися на зв'язку.
Speaker A
Е-е MQTT сам по собі добре масштабується. Один брокер у хмарі може обслуговувати тисячі пристроїв одночасно, тобто тисячі з'єднань підтримувати і обробляти мільйони повідомлень кожну годину. Тобто це типові показники, з якими працюють публічні MQTT брокери.
Speaker A
От ви на на лабораторній роботі кожен з вас публікував свої дані, да, і так по всьому світу на нього звертається.
Speaker A
звертаються клієнти. Ее він економний, тому для сервера це задача ось реальна. Щодо самих даних, QTT не обмежує якийсь конкретний формат повідомлень. Тобто можна передавати будь-яку інформацію, можна передавати текстову інформацію. Ми там рядки передавали. Їх можна в Jon упаковувати,
Speaker A
можна у вигляді якихось там двійкових бінарних даних передавати, можна таким чином кодувати будь-що. Тобто можна передавати зображення, можна передавати аудіо відеопотоки в MQTT. Ну, звісно, що він не на потокову інформацію орієнтований, а скоріше на порції інформації, але він
Speaker A
не накладає жодних обмежень. Тобто головне, щоб відправник і отримувач, там видавець і підписник, щоб вони знали, в якому форматі ці дані зберігаються.
Speaker A
То протокол прикладного рівня, а далі вже наверху домовленість про формат передачі даних. Ее MQTT лише накладає обмеження стосовно розміру повідомлень.
Speaker A
Тобто стандарт сам стандарт наTDT говорить, що максимальний розмір повідомлень може досягати 256 Мб. Ну, на практиці обмеження задає конкретний хмарний сервіс або брокер зазвичай в однозначно менші.
Speaker A
Секундочку. Да. Значить, е, ну, наприклад, е-е, IBM має е-е свій, е-е, сервіс хмарних послуг, який називається VSON.
Speaker A
Так ось, цей IBM Vson, він дозволяє обробляти дані в MQTT розміром до 128 КВ.
Speaker A
Там таке обмеження. Google - це інший провайдер хмарних послуг. Значить, також, е, часто в інтернеті ще використовується, е, він до 256 кб обмежує обсяг одного повідомлення.
Speaker A
Е-е, ну, також треба зазначити, що MQTT дає можливість взагалі передавати, е, повідомлення з нульовою довжиною корисних даних.
Speaker A
Це називається мло, тобто корисне навантаження, фактичні дані, да, там можна сформувати такий ее MQTT пакет, можна сказати, да, значить, повідомлення, яке взагалі не буде містити жодних. Це також за стандартом не заборонено.
Speaker A
Е-е, да. Значить, тепер важливою задачею брокера при обробці повідомленні є їх фільтрація. Фільтрація можлива за темами, по-перше.
Speaker A
Ну, тобто брокер дивиться на тему і передає підписникам лише відповідно ті повідомлення, що помічені теми, що помічені темами, на які ці підписники підписалися. Е, також можливо, що брокер, ее, буде фільтрувати за вмістом, тобто він може сам аналізувати дані, що
Speaker A
поступають, і за вказаними правилами там їх якось відсівати. Е, крім того, можлива фільтрація за типом даних повідомлення на рівні підписника, коли сам підписник аналізує вміст повідомлення о в тому самому пейлоді, в корисному навантаженні і вирішує далі, що з ним робити. Тобто це
Speaker A
не вбудований механізм протоколу самого, а вже логіка перекладного рівня. Тобто там що може бути? Ми ми сказали, що називається за типом даних.
Speaker A
Ну, типом, наприклад, може бути формат даних уйлоді. Там, якщо Jon, там є свої характерні особливості. Якщо там це текст, значить, можна текст розпізнати.
Speaker A
Тобто є певний там парсер, який визначає, що за тип цих даних. І далі вже на основі цього відбувається фільтрація.
Speaker A
Якщо це JON, значить, там може бути поле type. Воно може бути в різних значеннях.
Speaker A
там type значення. От він може тільки ці дані відбирати з тих, що йому надійшли.
Speaker A
Е-е, може на інші поля якісь дивитися. Тобто це вже залежить від конкретної реалізації підписника.
Speaker A
Далі, ну, ще треба сказати, що в останній версії MQDT 5.0 з'явилися так звані користувацькі властивості, там User Proper це називається.
Speaker A
Серед них там content type, device type, priority. І ось фільтрація може здійснюватися підписниками ще по цих додаткових користувацьких полях.
Speaker A
Стосовно MQTT треба зазначити, що він не є класичною чергою повідомлень. Класична черга працює якщо до неї поступила якась там інформація, якесь повідомлення, то вона буде отримувати, поки не хтось її не прочитає. Е, тут ситуація така. Якщо повідомлення було
Speaker A
відправлене брокеру, але брокер бачить, що ніхто не підписаний на цю відповідну тему, то це повідомлення буде втрачатись.
Speaker A
буде втрачено. Ну, є виняток збереження там збережувані повідомлення, але це окремий механізм. Ми про нього ще поговоримо.
Speaker A
Ее які механізми MQTT використовуються для забезпечення надійності і оптимізації передачі даних? Ее, значить, протокол має низку особливостей архітектурних, ее, які цікаво знати для того, щоб ним ефективно користуватися.
Speaker A
Ее, ми сказали, що попри назву, значить, message Q, да, Telemetri transпор MQTT розшифровується, е, фактично в ньому відсутня обов'язкова черга повідомлень.
Speaker A
Е-е, збережені повідомлення, ось ці самі, про які ми сказали, вони не є обов'язковим механізмом. Ну і ми сказали, що там передбачається встановлення з'єднання.
Speaker A
Та тобто підписник, коли підписується, встановлює з'єднання, видавець, коли ее хоче щось передати брокеру, він встановлює з'єднання. Е-е значить все це використо передбачає використання ее TCP.
Speaker A
От ми тут справа в нас тут по показано, що ее в Restful використовується TCP.
Speaker A
Ну, MQDT також використовує TCP, тобто TCP протокол з встановленням зітної. Е-е, значить, ну, це забезпечує нам певну вже базу для надійності доставки пакетів.
Speaker A
UDP, як ми знаємо, це на транспорті не забезпечує гарантованої доставки, а TCP забезпечує, хоча розроблявся він для дротових каналів зв'язку.
Speaker A
Важливою характеристикою NQTTT є те, що він є асиметричним протоколу на відміну від HTTP. Тобто ролі учасників різні. Один виступає ініціатором, інший приймачем.
Speaker A
Це добре узгоджується з моделлю датчики хмарна інфраструктура, але тут не клієнти і сервери, як ми сказали, да, а ролі видавців, підписників і брокера.
Speaker A
Ее так ось, значить, ключовою особливістю є збереження повідомлень на брокері протягом необмеженого часу. Тобто, ее, при передачі повідомлень, ее, вони можуть бути помічені спеціально, так що вони будуть зберігатися і автоматично насилатися кожному новому новому підписнику, який буде підписуватися на відповідну тему.
Speaker A
Да, тобто це дозволяє підписникам отримувати майже миттєво актуальний стан ситуації за цією темою. Значить, далі. Ну, що власне, які тут механізми? Механізми забезпечення надійності. Ее є така штука, є такий механізм, який називається остання воля і заповіт. Е, last will and testament.
Speaker A
Ну, ось тут в нас показано, значить, так звані LWT повідомлення. А значить, що це таке? Е-е, видавець під час підключення до брокера може задати спеціальне повідомлення LWT із заданою темою для того, щоб коли з'єднання з цим видавцем розірветься,
Speaker A
то ее причому розірветься некоректно, без підтвердження, да, цього, наприклад, через там втрату живлення або через помилку якісь якусь, то брокер автоматично чно буде розсилати ось це LWT повідомлення всім підписникам, що підписані на цю тему. І таким чином він
Speaker A
буде сигналізувати їм, підписникам, про аварійне відключення цього видавця. Тобто видавець одразу говорить, що якщо я зникну, то треба буде розіслати таки такий заповіт.
Speaker A
Остання воля і заповіт називається. Ну і далі працює. Якщо він зникає і певний час його немає на зв'язку, тоді розсилається це повідомлення як ее сигнал, що цей видавець пропав з радару, можна сказати, да? Значить, ми сказали, що хоча сам по
Speaker A
собі TCP на транспортному рівні начебто гарантує доставку, але він гарантує тоді, коли у нас з'єднання стабільне. А якщо з'єднання переривається, а так часто буває в бездротових мережах, то відповідно це проблемка може бути. Значить, в нас тоді Да, ну, до речі, власне, стосовно е-е
Speaker A
самих з'єднань, як це називається, встановлення з'єднань е-е MQTT, оскільки він розрахований на з'єднання, що можуть обриватися, він застосовує механізм keep life. Значить, е-е, на на основі таймерів він працює якраз для того, щоб відслідковувати, які з'єднання вони порвалися. Суть цього
Speaker A
механізму в тому, що клієнт і брокер періодично обмінюються службовими повідомленнями, що підтверджуп підтверджують активність з'єднання.
Speaker A
Тобто недостатньо просто встановити з'єднання і отримати підтвердження. Далі треба через певний час періодично його підтверджувати, що з'єднання у нас воно стабільне.
Speaker A
Ну, це повідомлення, яке називається PрекR і Pреesp. От ми там побачили, там конект є, да, а тут ще додаткові. Якщо протягом заданого часу обмін цими службовими повідомленнями не відбувається, то з'єднання буде вважатися розірваним. брокер таке з'єднання закриває і за потреби надсилає
Speaker A
ось це LWT повідомлення підписника. Е, ну, а якщо потім видавець з'явиться на зв'язку, то він може повторно потім підключитися і встановити нове з'єднання.
Speaker A
Далі, щоб зменшити накладні витрати при повторних підключеннях, Intстні сесії або з'єднання, або там постійні сесії або з'єднання. Значить, в цьому режимі брокер зберігає усі підписки клієнта, ее клієнта підписника та е також непідтверджені повідомлення та нові повідомлення, що були їм пропущені.
Speaker A
Тобто зникати можуть зв'язку не тільки видавці, як це часто буває, але і підписники. І от якщо так буває, що підписника немає, а повідомлення, значить, надсилалися для нього, коли була встановлена ось така персистентна сесія, значить брокер буде отримувати певний
Speaker A
час ці повідомлення. Е-е, значить, ідентифікація таких клієнтів здійснюється за, ну, через спеціальний параметр клієнт ID. І далі, коли він з'явиться на зв'язку, вони будуть якраз з черги вони будуть доставлені. Тобто це такий особливий випадок. Черга в даному випадку використовується. Вона може не
Speaker A
використовуватися, але в даному випадку буде використовуватись. Е для чого застосовується? Ну, для клієнтів, які мають особливий особливе значення, і вони мають отримувати всі повідомлення навіть після свого тимчасового відключення.
Speaker A
Далі, ще одним важливим аспектом забезпечення надійності передачі даних в MQTT є так звані рівні якості обслуговування Quality of Service.
Speaker A
Вони саме визначають надійність доставки повідомлень. Значить, утіity of service 0 - це мінімальний рівень ее доставки без гарантії.
Speaker A
Тобто, як кажуть, відправив і забув. Повідомлення надсилається без підтвердження і без повторів. Ну і якщо, наприклад, видавець надіслав повідомлення у пост нуль, то а підписник не на зв'язку, то він може таке повідомлення втратити. Звісно, що е-е якщо видавець
Speaker A
е-е передає свої дані з рівнем Quality of Service 1, то це вже називається гарантована доставка принаймні один раз, але при цьому можливі дублікати. Тобто, е-е, там працює такий механізм.
Speaker A
Ми не будемо зараз його розбирати цей механізм, але суть його в тому, що якщо є підозри на те, що, ну, наприклад, клієнт не не на зв'язку, да, то повторно надсилається це повідомлення. Потім, коли клієнт з'являється на зв'язку, він
Speaker A
може двічі отримати це повідомлення. Ну, але хоча б один раз він його отримав. Ну і нарешті Quality of Service 2 - це найскладніший алгоритм який забезпечує гарантовану доставку лише один раз гарантовано, тобто без дублікатів. Е-е, тобто там використовується складний механізм
Speaker A
підтверджень, який якраз і гарантує доставку рівно один раз. Ее і звісно, що він створює додатковий мережевий трафік, але якщо нам треба гарантувати, щоб не було дублікатів і підписник отримав обов'язково це повідомлення, ну тоді ми можемо цим пожертвувати.
Speaker A
Причому тут характерно важливо відмітити, що ось цей quality of service з одного боку він задається ее видавцем. Тобто видавець, коли пересилає, він задає, а з іншого боку він може затребуватися підписником. Тобто підписник, коли встановлює своє з'єднання з брокером,
Speaker A
він говорить: "Я бажаю отримувати повідомлення із таким-то рівнем доставки". Фактично Quality of Service буде представляти мінімальне значення з цих двох. Тобто, ее, якщо видавець, значить, публікує повідомлення на рівні Quality of Service 1, а підписник запитує на Quality of
Speaker A
Service 2, то, звісно, що він буде отримувати на рівні Quality of Service 1. Магії не буде, да? А-а, а якщо навпаки, значить, видавець публікує на Quality of Service 1, а підписник говорить: "Мені достатньо quality of service 0", значить, він буде отримувати на на рівні
Speaker A
quality of serv. Тото протокол мінімізує в будь-якому випадку ось ці накладні витрати на реалізацію механізмів якості обслуговування, якості доставки.
Speaker A
От значить тобто на практиці частіше за все використовується quity of service0. І ось саме ми в лабораторній роботі, якщо ми нічого не вказуємо додатково, да, то там буде використовуватися ось цей нульовий рівень доставки без гарантії. І ви бачили, що деякі повідомлення можуть
Speaker A
пропадати і не доходити до підписника, да, до MQTT експлорера. Він застосовується для швидких і некритичних даних, тобто які нам треба передавати без додаткових накладних витрат. Quality of service 1 - це компроміс між надійністю з одного боку і швидкістю
Speaker A
доставки з іншого. Ну, а Quality 2 це якраз для критично важливих застосувань, де помилки або дублікати є неприпустимими.
Speaker A
Так. Ну добре. Значить, такий ще момент важливий. Ее, значить, часто в документації навіть, е-е, підписників і видавцев назива називають клієнтами, а MQT брокери називають серверами.
Speaker A
Треба усвідомлювати, що ее взаємодія між ними не завжди відбувається у класичній схемі клієнт сервер, тому що підсвідомо, ну, ми собі так знаємо, що сервер він пасивний в тому випадку, що він очікує, да, тобто він постійно очікує, він не
Speaker A
ініціює е-е передачу, тобто він лише відповідає. Значить, клієнт в даному випадку активний, ну, в класичній архітектурі, да, клієнт активний, він ініціює запит і потім сервер асинхронно отримує цей запит і відповідає на клієнта. Клієнт працює в цьому сенсіхно з цими запитами. В даному випадку ми
Speaker A
бачимо, що коли, наприклад, підписник, да, підписується, то він є активним, тобто він ініціює запит на підписку, а потім він є пасивним, тобто він очікує, а вже брокер може ініціювати передачу, коли до нього поступили нові дані, то він буде ее вже по мірі того, як ці дані
Speaker A
будуть на нього надходити від видавців, він буде направляти їх підписникам. Тобто в даному випадку вони якби міняються місцями, да? Значить, брокер виступає в якості, ну, як якби клієнта, а, хоча це не можна сказати класичний класичний клієнт, да? Тобто він просто
Speaker A
буде ініціатором повідомлення, а значить підписник, да, він буде в режимі очікування знаходитися, хоча це не можна назвати, що він сервер. Ну, ось так іноді просто це плутає. Тобто, коли говорить клієнт, треба обов'язково говорити про що мається на увазі клієнт,
Speaker A
який клієнт підписник або клієнт-видавець. Але ще одна важливий момент, що існують пристрої, які можуть одночасно виконувати обидві ролі. Тобто вони можуть працювати як і видавці, і як підписники в одному флаконі, да, в одній коробці.
Speaker A
Так. Ну, далі, значить, тепер ми сказали, що, в принципі, сам по собі MQTT розроблявся для того, щоб вийти на хмару, да, тобто вийти у зовнішню мережу, упакувати дані і потім, ну, хоча вони він може також застосовуватися і в самій ее сенсорній
Speaker A
мережі, але для сенсорних мереж була згодом розроблена спеціальна похідна версія протоколу MQTT під назвою MQTTSN, тобто MQTT for Sensor Networks. Е, ця версія, вона, в принципі, на тій самій ідеології побудована, тобто легкий протокол для периферійних пристроїв, але, е-е, додатково оптимізована саме
Speaker A
під особливості бездротових середовищ. Тобто ще більш жорсткі вимоги, е, ну, тобто до низької пропускної здатності, до нестабільності каналів. е-е розраховано на короткі повідомлення і обмежені ресурси і пристроїв, що будуть реалізовувати відповідний функціонал.
Speaker A
Завдяки цій оптимізації е-е MQTTSN може ефективно працювати е поверх таких технологій, як Bluetooth Low Energy, Zigb та інші, тобто базових технологій зв'язку персональних і локальних мереж е в інтернеті речей.
Speaker A
Е-е, ми сказали, що сам по собі MQTT базується на TCP для того, щоб мати з'єднання, да? А MQTTSN він взагалі не потребує стеку TCPIP, хоча він може використовувати UDP, тобто він може працювати в стеку TCP, але не на TCP
Speaker A
протоколі, а на UDP. А може взагалі не використовувати СТЕК TCPIP, а працювати через якісь там послідовні з'єднання, наприклад, тобто якийсь власний протокол, наприклад, на ни на нижніх транспортних рівнях.
Speaker A
Е це ще додатково зменшує накладні витрати на нього. Ее значить особливостями значить компонентами MQTTSN в його архітектурі є шлюзи, форвардери, клієнти, видавці та підписники і брокери. Тобто клієнти і брокери - це те саме, що в нас було в
Speaker A
MQTT. Значить, а шлюзи і форвардери - це ось додаткові типи компонентів. Значить, шлюзи виконують перетворення між MQTTSN і MQTT просто.
Speaker A
і забезпечує таким чином взаємодію сенсорної мережі із хмарною інфраструктурою. Ее, в принципі, перекладати з MQTTSN на MQTT не складно, тому ця реалізація не потребує великих ресурсів. Е, форвардери - це пристрої, які передають дані від клієнтів ее в сенсорній мережі до
Speaker A
шлюзів, крайових шлюзів, інкапсулюючи повідомлення без змін і пересилаючи їх через мережу. Тобто, по суті, вони працюють як такі собі маршрутизатори в режимі передай далі. Тобто є задача просто передати далі і все. Ну, для того, щоб, наприклад, подовжити цю
Speaker A
лінію, цей маршрут для передачі до кройового маршрутизатора. Е-е, значить, ну, ось ми що тут бачимо, що в нас є м шлюз MQTTSN, є ще крайовий шлюз, крайовий маршрутизатор. Так. Так. Він також шлюс MQTTSN.
Speaker A
Е, ну і тут у нас датчики якісь, якісь прості датчики там бездротові. Вони по MQTTSN передають до цього шлюзу, а він перекладає на MQTT і далі вже направляє у хмару до провайдера хмарних послуг, до брокера MQTT. Якщо це якась потужна
Speaker A
система датчиків, наприклад, з на базі контролера да мікроконтролера то вона може сама реалізувати. Е-е, ну, в принципі, що тут самій реалізувати?
Speaker A
Вона взаємодіє напряму з шлюзом QTSN і він далі передає у хмар. Так, тобто він вже буде за NQTT працювати. Ее, брокер. Та от. Ну ідер, forвердер, значить, і він просто передає, да, в даному випадку крайовий маршрутизатор буде перекладати на MQTT,
Speaker A
а цей просто MQTTSN, MQTTSN видав і передав на ось цей шлюз. А тут вже він буде перекладати на MQTT просто.
Speaker A
До речі, шлюзи в MQTTSN бувають двох типів. Значить, тут в нас, здається, далі, да, значить, конфігурації шлюзів.
Speaker A
Є прозорі шлюзи і є агрегоючі шльози. Значить, прозорі шлюзи обробляють кожен потік даних, що до них поступив з кінцевих пристроїв окремо. Тобто вони фактично створюють відповідність один до одного. Тут у нас кожен потік вхідний перетворюється на один потік вихідний
Speaker A
один до одного. Ее, значить, з MQTTSN на MQTT. А агрегуючий шлюз, він декілька потоків приймає. Ось тут у нас наліво вони йдуть, да? І він далі їх мультиплексує, агрегує, перекладаючи на MQTT, і формує один вже мультиплексований потік. MQTT
Speaker A
повідомлення. Ее це, звісно, що більш складна реалізація, але вона, ее, але вона оптимізує власне е-е ресурси з'єднань брокера. Тобто брокер може ее не купу з'єднань підтримувати, да, MQTT, а з одним з'єднанням працювати, просто знаючи, як тут вони ці
Speaker A
повідомлення агреговані. Як правило, тут агрегуються повідомлення по одній темі. Частіше за все, агрегуючий шлюз повідомлення з однією е-е темою.
Speaker A
Значить, основними відмінностями MQTTSN від MQTT просто е-е є розширений механізм з'єднання. Е тобто коли встановлюється з'єднання, то там три типи цих з'єднань підтримуються. Можливість роботи без TCPIP. Ми сказали використання коротких ідентифікаторів тем замість повних імен.
Speaker A
Це додатково економить пропускну здатність. Підтримка попередньо визначених тем без реєстрації. Наявність механізму виявлення шлюзів і серверів у мережі.
Speaker A
Модифікований механізм KPI, орієнтований на сплячих клієнтів, при якому повідомлення буферизуються і передаються після їх пробудження. Тобто, в принципі, і в MQTT є подібна штука, да, але в MQTTsNзм був модифікований.
Speaker A
Ну, ось так. Тобто ми познайомилися з основними аспектами роботи MQTT та MQTTSN. І тепер краще, я думаю, собі представляємо, що відбувається, коли ми е-е виконуємо третю лабораторну роботу.
Speaker A
Взагалі протоколів, які використовуються для передачі даних з персональних сенсорних мереж у хмару, їх багато. Ее, ну, скажімо так, другий по популярності і перспективний протокол, що застосовується для вирішення цієї задачі - це обмежений прикладний протокол під назвою Club. Значить, Constraint
Speaker A
Application Protocol. Ну, це іноді перекладається як протокол обмеженого застосування, хоча він також працює на прикладному рівні, тому він прикладний. Е, це також легкий мережевий протокол, спеціально розроблений для пристроїв інтернету речей, для пристроїв з обмеженими ресурсами, що для інтернету
Speaker A
речей ее характерно. Значить, і розроблявся він якраз як більш проста та енергоефективна альтернатива HTTP.
Speaker A
Тобто розробники цього протоколу, вони подумали: "Може сама по собі концепція і не така собі погана, але якщо її оптимізувати добре, вона може запрацювати і для інтернету речей також".
Speaker A
Значить важливо що працює поверх DP, а не поверх TCP, як HTTP. І це перший крок на шляху зменшення накладних витрат, от, і забезпечення більш ефективної передачі даних. Протокол КАП підтримує виявлення ресурсів, керування ресурсами, спостереження за їх станом, а також
Speaker A
асинхронний обмін повідомленнями і кешування. І це робить його якраз зручним, функціональним і придатним для його застосування.
Speaker A
Розроблений цей протокол був організацію IETF у межах робочої групи Коре. Він стандартизований потім в документах RFC.
Speaker A
Ее він є одним з перших протоколів, створених спеціально для взаємодії між машинами, для між машинної взаємодії на рівні граничних пристроїв.
Speaker A
Важливою особливістю цього протоколу є вбудована підтримка взаємодії з HTTP через проксі, що дозволяє інтегрувати його пристрої з традиційним інтернетом.
Speaker A
При цьому Коап зберігає знайому для вебу модель адресації ресурсів, але забезпечує її реалізацію з меншими витратами, з меншими витратами ресурсів.
Speaker A
Значить, архітектура Коа базується на іделі на ідеї полегшеної реалізації принципів HTTP, зокрема рест підходом.
Speaker A
Ее сам по собі QА подібний до HTTP за логікою роботи, але використовує е-е транспорт UDP, так званий безз'єднаний, да, тобто без використання встановлених з'єднань. Підтримує асинхронний обмін, має мінімалістичні заголовки і низькі накладні витрати. Крім того, він використовує захист на основі DTLS
Speaker A
замість TLS. Коа підтримує URI, тобто ідентифікатори ресурсів та типи вмісту, що робить зручним його для роботи з ресурсами.
Speaker A
Так, да. От у нас є така картинка. Значить, Steк HTTP і Steck Oupp. Значить, ну, стек HTTP, в принципі, він може працювати на базі різних технологій. Ми можемо, ее, до сайтів, да, HTTP звертатися по ее різних технологіях зв'язку. Можемо мобільний
Speaker A
інтернет використовувати, можемо продротовий інтернет використовувати. Тобто на канальному фізичному рівні, в принципі, можуть працювати різні технології.
Speaker A
Далі, як правило, це IP. Ну, поки що частіше IP V4, може, IP V6. Тому тут так універсально написано, а потім TCP.
Speaker A
Тут ми бачимо, що Steck COAP частіше за все працює на базі ее технології I triple i802154.
Speaker A
На канальному рівні для цього, наприклад, може використовуватися технологія sixlow Pen. На IP рівні, значить, IPви V6 і на транспортному UDP.
Speaker A
Ну, а що стосується власне прикладного рівня, там де працює Коап, там де він реалізований, то там можна виділити ще два підрівні.
Speaker A
Значить, перший - це рівень запиту відповіді, який реалізує, власне, рест взаємодію, тобто запити на по типу get, put, post, delete і відповідні відповіді на ці запити.
Speaker A
А під ним працює рівень транзакцій. який відповідає за обмін повідомленнями між вузлами, включаючи механізми підтвердження повторної передачі, багатокастової розсилки і контролю перенавантаження.
Speaker A
Да, адресація в Коап побудована. Я тут не писав, здається, написав. А куди воно ділося?
Speaker A
Десь поділася це напис. Цей напис. Значить, адресація організована за аналогією HTTP. і використовує URL структуру типу COAP 2крап два слеша, потім host там або IPV6 адреса. От потім 2крапкапорт можливо вказати потім спадатковий шлях і потім знак питання query. Тобто
Speaker A
запит конкретний йде. Тобто знайома нам схема е-е адресації е-е ресурсів, адресації сервісів, адресації запитів.
Speaker A
Е коди відповідей також подібні до HTTP. Наприклад, там відповідь створено, відповідь видалено, відповідь не знайдено. Це взагалі спрощує розуміння і інтеграцію з існуючою інфраструктурою HTTP. Тобто ми бачимо, що таким чином виглядає як спрощений аналог HTTP, створений, адаптований для умов
Speaker A
інтернету речей. Поєднує знайому веб-модель з мінімальними вимогами до ресурсів і забезпечує ефективну взаємодію між обмеженими пристроями.
Speaker A
Да, що стосується архітектури, то в протоколі КОП система взаємодії будується навколо декількох ключових учасників. Кожен з них виконує свою роль. Основні ці кінцеві точки, так звані endpints, це в нас клієнти і сервери.
Speaker A
Ось у нас кінцевий клієнт, кінцевий сервер. Це і є ось ті самі кінцеві точки endpints.
Speaker A
А-а, значить, одні такі пристрої виступають джерелами Коап повідомлень, інші отримувачами. І їх конкретна реалізація залежить від того транспорту, на базі якого працює кла.
Speaker A
А важливу роль відіграють проксі. Ось у нас тут посередині є проксі. Ее значить проксі є спеціальними кінцевими точками, що можуть виконувати запити від імені клієнтів. Тобто вони дозволяють зменшити навантаження на мережу, забезпечують доступ до сплячих пристроїв.
Speaker A
і додатково підвищити рівень безпеки. Тобто, в принципі, вони вирішують ті самі задачі, що і звичайні проксі в мережах. Е, проксі можуть працювати в різних режимах.
Speaker A
Вони можуть бути явно заданими клієнтом. Це називається пряме проксування, а можуть діяти як проміжні сервери. Це називається зворотне проксування.
Speaker A
Також вони можуть перетворювати запити між різними протоколами. Наприклад, Squа перекладати на HTTP. Якщо нам треба інтегруватися з HTTP якимось хмарним сервісом, значить, можна для цього також проксі використовувати.
Speaker A
У класичній моделі взаємодії клієнт ініціює запит, сервер його обробляє і формує відповідь. Існує також поняття посередника, тобто intermediar е-е проміжний вузол, який одночасно виступає і клієнтом, і сервером щодо інших вузлів.
Speaker A
От якраз проксі, вони являються такими посередниками. Ну і також тут у нас в архітектурі є початкові сервери.
Speaker A
Їх також називають серверами походження Origin Servers. Тобто це сервери, на яких фактично розміщаються ресурси, ее до яких звертаються клієнти. Ну, тобто якісь клієнти можуть знаходитися тут, якісь сервери можуть знаходитися тут, да, але функціонал основний, який нас цікавить, це в хмарі,
Speaker A
да, він знаходиться, да? Значить, і є ще така штука, як спостерігач, такий компонент обсервер.
Speaker A
Значить е-е клієнт може зареєструватися як спостерігач ресурсу, е, використовуючи модифікований запит get і після цього отримувати нові повідомлення щоразу, коли стан ресурсу, на який він підписався, змінюється.
Speaker A
Тобто фактично спостерігачі це аналоги MQTT підписників. Таку саму модель підписки вони реалізують, але в межах не MQTT, а в межах REST підходу.
Speaker A
Е, взагалі архітектура КОБ дозволяє як пряму взаємодію між клієнтами і серверами, так і інтеграцію з хмарними сервісами через проксі.
Speaker A
Кінцеві точки можуть взаємодіяти на рівні сенсорів, а спостерігачі забезпечують реакцію на зміни стану ресурсів у реальному часі.
Speaker A
Для зв'язку протокол за замовченням використовує порт 5683, а у випадку використання захищеного обміну ДТЛС порт 5684.
Speaker A
Тобто ось ми тут бачимо, що COAP взаємодія може реалізовуватися безпечно з DТС, да? М так. Значить, ну і до речі, до речі, е тут у нас є два типи проксі. Ось ми бачимо, що тут є середній проксі перетину і є середній
Speaker A
проксі напрямний. Е, напрямний проксі англійською цефордінг проксі називається. Е, він просто пересилає коа запити і далі без зміни, без зміни протоколу. проксі перетину кроспро, значить, виконують перетворення між протоколами, наприклад, з коап перекладають на http або https і таким чином забезпечують зв'язок між
Speaker A
i-мережею з одного боку, та ось тут у нас iмережа і веб-сервісами у хмарі. Так, ну добре. Значить, по протоколах є якісь питання?
Speaker A
Нема. Немає питань. Так, ну добре. В принципі, існують і інші протоколи. Також вони цікаві, але нам треба йти далі. Ми познайомилися з двома найбільш відомими з них.
Speaker A
І наступна тема, да, ну тут є можна довго ще розказувати, яка там які повідомлення, запити відповідь, що підтверджуються, чи не підтверджуються. Ми не будемо зараз на цьому останавлюватися, зупинятися.
Speaker A
Давайте перейдемо до наступної теми. Технології дальнього зв'язку. Е, от ми, в принципі, вже знаємо, що в інтернеті речей розташовується велика кількість різнорідних пристроїв, там датчики, виконавчі механізми, ее пристрої, що оснащуються цими сенсорними модулями, там камерами, наприклад, транспортні засоби, роботи, інтелектуальні вбудовані
Speaker A
системи. Все це може охоплювати великі території. Вони можуть працювати у якихось там важкодоступних місцях. ее на віддалених якихось там локаціях. І для забезпечення обміну е даними між такими пристроями на великих відстані треба вже виходити за межі локальних мереж, да, і
Speaker A
утворювати глобальні мережі. Ну, ми вже знаємо, що можлива ситуація, коли в нас пристрої групуються в якійсь місцевості, да, ми можемо утворити там локальну мережу, а далі через шлюзи направляти вже до інтернету. Інший варіант - це коли ми намагаємося власними, скажімо
Speaker A
так, технологіями охопити великі території. І от що тут в нас є, тобто які існують технології для дальнього зв'язку, окрім того, що ми розглянули як варіант е через шлюз на інтернет вийти, чим ми можемо утворювати ті самі глобальні мережі, які виступають в
Speaker A
якості інфраструктури в зв'язку для ее великих, можна сказати, сенсорних мереж, якщо можна так сказати, да, великих сенсорних мереж.
Speaker A
Ее, значить, взагалі глобальна обчислювальна мережа може будуватися на базі, частіше за все, да, може будуватися на базі систем стільникового зв'язку, тобто мобільний зв'язок, те, що ми називаємо там 3G, 4G, 5G, а також на базі спеціалізованих технологій для інтернету речей, таких як Лора і Sfox.
Speaker A
Ось це те, що власне ми будемо розглядати у цій темі. Ну і почнемо ми з стільникового зв'язку.
Speaker A
Ее це дуже поширений спосіб передачі даних на великій відстані стільниковий радіозв'язок. Розвиток ее ці цих цієї технології має тривалу історію ще в 40-х-50-х роках минулого століття. проводилися перші експерименти з мобільним зв'язком. Тоді ще стандартів не було, були великі технічні обмеження,
Speaker A
тобто в основному це було так, як експериментально. А системи, які створювалися тоді, вони такого широкого застосування ще не набули.
Speaker A
Після формування концепції стільникової мережі, запропонованої дослідниками з Bellabs у 60-х роках відбувся свого роду прорив. І важливим кроком тут стало впровадження механізму handover, так званого, тобто передачі з'єднання між базовими станціями. Тобто користувач залишається на зв'язку під час переміщення від однієї базової станції
Speaker A
до іншої через цей механізм. Ее, ну і ключовою ідеєю стільникового зв'язку став якраз поділ території на комірки Cells. Ось ці стільники, які зазвичай моделюються як шестикутники. Тобто саме та така структура дозволяє найбільш ефективно використовувати радіочастоти, уникаючи завад між сусідніми комірками. Ну і
Speaker A
водночас забезпечує можливість повторного використання частот у віддалених зонах. Тобто саме така структура і стала основою масштабованості стільникових мереж, мобільних мереж. Комерційне впровадження стільникового зв'язку розпочалося наприкінці 70-х років минулого століття. Перші моделі були запущені японською компанією NPON Telegraph and Telepone у 79му році, а
Speaker A
згодом вони появилися вже у країнах Європи та Америки. Ці системи отримали назву 1G, перше покоління мобільного зв'язку. А далі розвиток технологій привів вже до появи нових поколінь, які поступово вдосконалювали швидкість передачі даних, надійність і функціональність.
Speaker A
Ну, зараз ми працюємо, всі користуємося, е 3G 4G LTE е-е, як основою мобільної передачі даних.
Speaker A
Існують і більш нові технології, які більш ще більш підходять для інтернету речей, власне, аніж універсальний мобільний зв'язок.
Speaker A
Тобто завдяки тому, що вони спеціально орієнтовані на підтримку великої кількості пристроїв із низьким енергоспоживанням і малими обсягами даних, що передаються.
Speaker A
У сфері мобільного та дальнього зв'язку ключову роль відіграють міжнародні організації, що визначають стандарти. І вони таким чином визначають напрямки розвитку цих технологій.
Speaker A
Ми говорили вже про ITU, що це одна з головних таких організацій, Міжнародна спілка електрозв'язку.
Speaker A
До речі, вона була заснована ще у 1865 році. в X столітті. Зараз вона об'єднує майже всі країни світу, сотні організацій і відповідає за розробку глобальних стандартів у сфері бездротового зв'язку, мобільних технологій, передачі даних та інтернету. У структурі цієї Міжнародної
Speaker A
спілки електрозв'язку важливе місце займає сектор ITUR, тобто МСР. Ее, значить, за радіозв'язок він відповідає і визначає вимоги до, зокрема, до поколінь стільникового зв'язку.
Speaker A
Саме ось цей сектор ITUR сформував базові специфікації для розвитку мобільних мереж. Ее, значить, важливо ось що розуміти, що, е, ITR, ее, формує формулює цілі та вимоги до відповідних поколінь зв'язку.
Speaker A
Тобто він, ее, ставить вимоги, але не говорить, як саме це їх треба досягти цих вимог.
Speaker A
А паралельно з ITR діє ще одна важлива організація, яка називається 3GPP, тобто третього покоління, да? Значить, вона об'єднує провідні телекомунікаційні структури світу і вона вже вирішує задачу розробляти конкретні технічні специфікації та стандарти, що реалізують вимоги, які були визначені ITUR саме в
Speaker A
межах 3GP. І розвиваються такі технології, як УТЕ. Організація ця працює через технічні групи та регулярні релізи. І головною метою цих релізів є забезпечення сумісності між різними поколіннями обладнання та мереж.
Speaker A
Ее, тобто, в принципі, можна сказати, що ITR формулює цілі для та вимоги для поколінь зв'язку, а GPP розробляє технології для досягнення цих цілей. І потім вже ITR ее підтверджує відповідність цих технологій 3GPP е цим стандартом, що він сам висунув. Та тому
Speaker A
навколо термінів е-е іноді виникає плутанина, тобто що собою представляє LTE і що собою представляє 4G, як вони пов'язані між собою. Значить 4G умовно, да, вимога, а LTE- технологія для її реалізації.
Speaker A
Е-е, значить, ну добре. Так, у нас зараз лекція підійшла до кінця. Робимо перерву. Продовжимо через півгодини.
Speaker A
Добре. Я перепрошую, я там запізнися трошки. Відміцли мене чи ні? Так візьміть атаку.
Topics:Інтернет речейMQTTHTTPRESTпротоколи передачі даниххмарні технологіїmessage oriented middlewareброкер MQTTIoT протоколитехнології зв’язку
