IoT-W7 PDF - Internet of Things
Document Details
Uploaded by Deleted User
Nile University
Tags
Summary
This document is lecture notes about the Internet of Things (IoT) and cloud computing for a computer science course at Nile University. It covers fundamental concepts, applications, and various aspects of IoT. Topics include human-computer interfaces, sensing, actuation, sensor networks, IoT cloud integration, and more.
Full Transcript
CSCI410 Nile University- School of Information Technology and Computer Science Internet-of-Things (IoT) Lecture Lab Fundamentals of IoT, basic Basic Python & Raspberry Pi Week concepts, applications programming...
CSCI410 Nile University- School of Information Technology and Computer Science Internet-of-Things (IoT) Lecture Lab Fundamentals of IoT, basic Basic Python & Raspberry Pi Week concepts, applications programming 1 Human-computer Sensor programming, control Week interfaces, sensing, loops, digital/analog I/O 2 actuation Course Week Fundamentals of computer and wireless Wi-Fi and Bluetooth networks, network 3 Overview networks Sensor networks, mesh measurements ZigBee, WPANs, WBANs, Week networks, routing, WPANs routing, network 4 measurements Processing, IoT cloud, IoT cloud integration, sensor Week analytics, visualization fusion, analytics, 5 visualization RFID, IoT ecosystem, Final project Week security, privacy, ethics, 6 case studies CoAP MQTT What is MQTT Essentials Part 1 Features & Characteristics of MQTT | MQTT Essentials Part 2 Pub Sub Model | MQTT Essentials Part 3 MQTT Client Broker Setup | MQTT Essentials Part 4 MQTT Publish / Subscribe / Unsubscribe | MQTT Essentials Part 5 MQTT Topic Best Practices | MQTT Essentials Part 6 MQTT QoS - Quality of Service | MQTT Essentials Part 7 Persistent Session and Message Queue | MQTT Essentials Part 8+ MQTT Retained messages | MQTT Essentials Part 9 MQTT Example Node Red installation: link Example: Raspberry Pi Node-Red Use MQTT To Communicate Between Two Raspberry Pi Devices QaAP Example: local host : link INTERNET of Things IoT EcoSystem Weeks 5&6 Week 1 Week 1 Week 2 Week 2 Weeks 3&4 What is Cloud Computing? What is Cloud Computing? servers storage Delivery of computing analytics services databases networking and much more... Another definition: network-based computing taking place over the Internet, while hiding complexity of underlying infrastructure using simple APIs What is Cloud Computing? Collection/group of integrated and networked Platforms provide on demand services that are hardware, software, and Internet infrastructure always on and accessible anytime and anywhere (called a platform) What is Cloud Computing? Advantages: New applications Anytime/anywhere access Homogeneity Virtualization Resilient Cost Sharing, collaboration Management/maintenance Security … Definitions Virtualization: creation of a virtual resource such as a server, desktop, operating system, file, storage, or network Middleware: software that acts as a bridge between an operating system or database and applications, especially on a network Runtime: software designed to support the execution of computer programs Cloud Models: IaaS, PaaS, SaaS Simple example: IaaS: barebones computer PaaS: computer + OS (incl. development environment) SaaS: complete solution including application(s) IaaS, PaaS, SaaS IaaS: Amazon Web Services (AWS), Microsoft Azure, Google Compute Engine IaaS, PaaS, PaaS: Google App Engine, Heroku, OpenShift, AWS Elastic Beanstalk SaaS SaaS: Google Apps, Dropbox, Cisco Webex, Salesforce, Concur, GoToMeeting “No-need-to-know”: interact with underlying infrastructure via API Flexibility and elasticity: scale systems up and down (allocate/release Basic Cloud resources) based on needs Characteristics Pay as much as used and needed (actual usage vs. service levels) Anytime anywhere access App App App OS OS OS Virtualization Hypervisor Hardware Virtualized Stack Virtual workspaces: An abstraction of an execution environment that can be made dynamically available to authorized clients by using well-defined protocols Resource quota (e.g., CPU, memory share) Software configuration (e.g., OS, provided services) Implemented on Virtual Machines (VMs): Abstraction of a physical host machine Hypervisor intercepts and emulates instructions from VMs, and allows management of VMs VMWare, VirsualBox, Xen, etc. Virtual Machines App App App App App Xen Guest OS Guest OS Guest OS (Linux) (NetBSD) (Windows) VMWare VM VM VM Virtual Machine Monitor (VMM) / Hypervisor UML Hardware Denali etc. Cloud Example: S3 Amazon Simple Storage Service (S3) Unlimited storage Pay for what you use Cloud Example: EC2 Amazon Elastic Compute Cloud (EC2) Virtual computing environments (“instances”) Pre-configured templates for instances Launch as many virtual servers as needed (“elastic”) Xen and KVM hypervisor Do You Use The Cloud? Cloud for IoT Blynk HyperText Transfer Protocol (HTTP) Clients and servers communicate using the HyperText Transfer Protocol (HTTP) Client and server establish TCP connection Client requests content Server responds with requested content Client and server close connection (usually) HTTP request Web Web client server (browser) HTTP response (content) Static & Dynamic Content Static content: content stored in files and retrieved in response to an HTTP request The content returned in HTTP Examples: HTML files, images, audio clips responses can be either static or Dynamic content: content produced on-the-fly in response to an HTTP request dynamic Example: content produced by a program executed by the server on behalf of the client Bottom line: all web content is associated with a file that is managed by the server Web Content Example MIME types Web servers return content to clients text/html HTML document a sequence of bytes with an associated MIME text/plain (Multipurpose Internet Mail Extensions) type Unformatted text application/postscript Postcript document image/gif Binary image encoded in GIF format image/jpeg Binary image encoded in JPEG format Each file managed by a server has a unique name called a URL (Universal Resource Locator) URLs for static content: http://www.cse.nd.edu:80/index.html http://www.cse.nd.edu/index.html http://www.cse.nd.edu Identifies a file called index.html, managed by a web server at www.cse.nd.edu that is listening on port 80 URLs URLs for dynamic content: http://www.cse.nd.edu:8000/cgi- bin/adder?15000&213 Identifies an executable file called adder, managed by a web server at www.cse.nd.edu that is listening on port 8000, that should be called with two argument strings: 15000 and 213 unix> telnet www.aol.com 80 Client: open connection to server Trying 205.188.146.23... Telnet prints 3 lines to the terminal Connected to aol.com. Escape character is '^]'. GET / HTTP/1.1 Client: request line host: www.aol.com Client: required HTTP/1.1 HOST header Client: empty line terminates headers. Anatomy of an HTTP/1.0 200 OK Server: response line HTTP MIME-Version: 1.0 Date: Mon, 08 Jan 2001 04:59:42 GMT Server: followed by five response headers Transaction Server: NaviServer/2.0 AOLserver/2.3.3 Content-Type: text/html Server: expect HTML in the response body Content-Length: 42092 Server: expect 42,092 bytes in the resp body Server: empty line (“\r\n”) terminates hdrs Server: first HTML line in response body... Server: 766 lines of HTML not shown. Server: last HTML line in response body Connection closed by foreign host. Server: closes connection unix> Client: closes connection and terminates HTTP Requests HTTP request is a request line, followed Request line: by zero or more request headers is HTTP version of request (HTTP/1.0 or HTTP/1.1) is typically URL for proxies, URL suffix for servers is either GET, POST, OPTIONS, HEAD, PUT, DELETE, or TRACE URI: Uniform Resource Identifier Ex: mailto:[email protected] tel:+1-212-555-1212 HTTP methods: GET: Retrieve static or dynamic content Arguments for dynamic content are in URI Workhorse method (99% of requests) POST: Retrieve dynamic content HTTP Arguments for dynamic content are in the request body OPTIONS: Get server or file attributes Requests HEAD: Like GET but no data in response body Query resources information before GET PUT: Write a file to the server DELETE: Delete a file on the server TRACE: Echo request in response body Useful for debugging HTTP Responses HTTP response is a response line followed by zero or more response headers Response line: is HTTP version of the response is numeric status is corresponding English text 200 OK Request was handled without error 403 Forbidden Server lacks permission to access file 404 Not found Server couldn’t find the file Response headers: : Provide additional information about response Content-Type: MIME type of content in response body Content-Length: Length of content in response body REST Representational State Transfer (REST) A style of software architecture for distributed hypermedia systems such as the World Wide Web A collection of network architecture principles which outline how resources are defined and addressed The motivation for REST was to capture the characteristics of the Web which made the Web successful 1. URI Addressable resources REST & 2. HTTP Protocol 3. Make a Request – Receive Response – Display Response HTTP Exploits the use of the HTTP protocol beyond HTTP POST and HTTP GET 1.HTTP PUT, HTTP DELETE REST REST is not a standard is an architectural style But it uses several standards: HTTP URL XML/HTML/GIF/JPEG/etc (Resource Representations) text/xml, text/html, image/gif, image/jpeg, etc (Resource Types, MIME Types) REST Main Concepts Nouns (Resources) unconstrained i.e., http://example.com/employees/12345 REST Verbs Representations constrained constrained i.e., GET i.e., XML Resources The key abstraction of information A resource is a conceptual mapping Represented with a global identifier in REST is a resource to a set of entities (URI in HTTP) Any information that can be named can be a http://www.boeing.com/aircraft/747 resource: a document or image, a temporal service (e.g., “today's weather in Berlin”), a collection of other resources, a non-virtual object (e.g., a person), etc. Represent the actions to be performed on resources HTTP GET HTTP POST Verbs HTTP PUT HTTP DELETE HTTP GET How clients ask for the information they seek Issuing a GET request transfers the data from the server to the client in some representation http://localhost/books GET http://localhost/books Retrieve all books http://localhost/books/ISBN-0011021 GET http://localhost/books/ISBN-0011021 Retrieve book identified with ISBN-0011021 http://localhost/books/ISBN-0011021/authors GET http://localhost/books/ISBN- http://localhost/books/ISBN-0011021/authors Retrieve authors for book identified with ISBN-0011021 0011021/authors HTTP PUT & POST HTTP POST creates a resource HTTP PUT updates a resource POST http://localhost/books/ http://localhost/books/ PUT http://localhost/books/isbn-111 http://localhost/books/isbn-111 Content: {title, authors[], …} Content: {isbn, title, authors[], …} Creates a new book with given properties Updates book identified by isbn-111 with submitted properties Representations How data is represented or returned to the client for presentation. JavaScript Object Notation (JSON) Two main formats: XML It is common to have multiple representations of the same data Representations XML CS2650 Distributed Multimedia Software JSON {course {id: CS2650} {name: Distributed Multimedia Software} } CoAP Constrained Application Protocol REST-based web transfer protocol manipulates Web resources using the same methods as HTTP: GET, PUT, POST, and DELETE subset of HTTP functionality re-designed for low power embedded devices such as sensors (for IoT and M2M) CoAP TCP overhead is too high and its flow control is not appropriate for short- lived transactions UDP has lower overhead and supports multicast CoAP Four message types: Confirmable – requires an ACK Non-confirmable – no ACK needed Acknowledgement – ACKs a Confirmable Reset - indicates a Confirmable message has been received but context is missing for processing CoAP CoAP provides reliability without using CoAP enables asynchronous Also supports multicast and congestion TCP as transport protocol communication control e.g., when CoAP server receives a request which it cannot handle immediately, it first ACKs the reception of the message and sends back the response in an off- line fashion CoAP CoAP is A RESTful protocol What CoAP Both synchronous and asynchronous Is For constrained devices and networks Specialized for M2M applications Easy to proxy to/from HTTP BREAK Message Queuing Telemetry Transport In a nutshell, MQTT consist of three parts: MQTT Broker Subscribers Publishers MQTT MQTT MQTT was invented by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link) back in 1999, where their use case was to create a protocol for minimal battery loss and minimal bandwidth connecting oil pipelines over satellite connections. They specified the following goals, which the future protocol should have: Simple to implement Provide a Quality of Service Data Delivery Lightweight and Bandwidth Efficient Data Agnostic Continuous Session Awareness MQTT Built for proprietary You can send anything as Built for unreliable embedded systems; now a message; up to 256 networks shifting to IoT MB Message have a topic, Enterprise scale Decouples readers and quality of service, and implementations down writers retain status associated to hobby projects with them Publish/Subscribe Concept Decoupled in space and time: The clients do not need each others IP address and port (space) and they do not need to be running at the same time (time). The broker’s IP and port must be known by clients Namespace hierarchy used for topic filtering It may be the case that a published message is never consumed by any subscriber MQTT: Example Clients connect to a “Broker” Clients subscribe to topics e.g., client.subscribe(‘toggleLight/1’) client.subscribe(‘toggleLight/2’) client.subscribe(‘toggleLight/3’) Clients can publish messages to topics: client.publish(‘toggleLight/1’, ‘toggle’); client.publish(‘toggleLight/2’, ‘toggle’); All clients receive all messages published to topics they subscribe to Messages can be anything Text Images etc. var mqtt = require('mqtt'); var client = mqtt.createClient('', 'm11.cloudmqtt.com', { username: '’, password: '' }); Node.js client.on('connect', function () { // When connected Example // subscribe to a topic client.subscribe('TEMPERATURE_READING', function () { // when a message arrives, do something with it client.on('message', function (topic, message, packet) { console.log("Received '" + message + "' on '" + topic + "'"); }); }); // publish a message to a topic client.publish('SET_TEMPERATURE', '24', function () { console.log("Message is published"); }); }); Topics Each published data specifies a topic Each subscriber subscribed to that topic will receive it Topic format: separator /home/rooms/kitchen/temperature sub-topic sub-topic sub-topic sub-topic Durable/Transient Subscriptions Subscriptions Durable If the subscriber disconnect messages are buffered at the broker and delivered upon reconnection Non-durable Connection lifetime gives subscription lifetime M1 M2 M3 M4 M5 M6 Subscription Durable Connection Connected Connected Publications Retained (“persistent” message) The subscriber upon first connection receives the last State good publication (i.e., does not have to wait for new publication) Retention One flag set both in the publish packet to the broker and in the published packet to the subscribers Only the most recent persistent message is stored and distributed Session Aware Last Will and Testament (LWT) – topic published upon disconnecting a connection Any client can register a LWT Anybody subscribing to the LWT topic will know when a certain device (that registered a LWT) disconnected Protocol Stack Application MQTT SSL optional TCP IP TCP/IP Port: 1883 When running over SSL, TCP/IP port 8883 SSL: Secure Socket Layer (encryption) "QoS" Quality of Service Publishing “QoS” 0 – unreliable (aka “at most once”) OK for continuous streams, least overhead (1 message) (Reliability) “Fire and forget” TCP will still provide reliability 1 – delivery “at least once” (duplicates possible) Publishing “QoS” Used for alarms – more overhead (2 messages) Contains message ID (to match with ACKed message) (Reliability) Publishing “QoS” 2 – delivery “exactly once” Utmost reliability is important – most overhead (4 messages) and (Reliability) slowest Publishing “QoS” (Reliability) Moreover, all subscribers also maintain their inflight message queue, which allows them to compare incoming messages with those already received. This action ensures that a subscriber forwards the message to the coupled mechanisms once only. If the subscriber receives the PUBREL packet, it will delete the message from its inflight message queue and inform the broker about it by sending a PUBCOMP command. Publishing “QoS” (Reliability) Reliability maintained even if the TCP Separate QoS for connection breaks publishing and for (intermittent subscribing connections) MQTT Message Shortest Message is Two Bytes Format Message Types Message Types Both used CoAP: MQTT: in IoT one-to-one many-to-many communication communication Comparison UDP/IP unreliable TCP/IP focus on CoAP & MQTT lightweight and message easy to delivery; implement reliable higher overheads (protocol data, processing costs) BREAK