Internet-of-Things (IoT)

Khondaker A. Mamun, PhD.

Director, AIMS Lab
Professor, CSE,UIU

Acknowledgement
University of Notre Dame
Course Overview
Lecture Lab
Fundamentals of IoT, basic Basic Python & Raspberry Pi
Week 1 concepts, applications programming

Human-computer interfaces, Sensor programming, control

Week 2 sensing, actuation loops, digital/analog I/O

Fundamentals of computer and Wi-Fi and Bluetooth networks,

Week 3 wireless networks network measurements

Sensor networks, mesh ZigBee, WPANs, WBANs, routing,

Week 4 networks, routing, WPANs network measurements

Processing, IoT cloud, analytics, IoT cloud integration, sensor

Week 5 visualization fusion, analytics, visualization

RFID, IoT ecosystem, security, Final project

Week 6 privacy, ethics, case studies
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?
• Delivery of computing services
– servers
– storage
– analytics
– 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 hardware, software, and
Internet infrastructure (called a platform)

• Platforms provide on demand services that are

always on and accessible anytime and
anywhere
What is Cloud Computing?
• Advantages:
– New applications
– Anytime/anywhere access
– Homogeneity
– Virtualization
– Resilient
– Cost
– Sharing, collaboration
– Management/maintenance
– Security
– …
Cloud Models: IaaS, PaaS, SaaS
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
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

• PaaS: Google App Engine, Heroku, OpenShift,

AWS Elastic Beanstalk

• SaaS: Google Apps, Dropbox, Cisco Webex,

Salesforce, Concur, GoToMeeting
Basic Cloud Characteristics
• “No-need-to-know”: interact with underlying
infrastructure via API
• Flexibility and elasticity: scale systems up and
down (allocate/release resources) based on
needs
• Pay as much as used and needed (actual usage
vs. service levels)
• Anytime anywhere access
Virtualization
• 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
App App App
– VMWare, Xen, etc.
OS OS OS
Hypervisor
Hardware
Virtualized Stack
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
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)
Web Content
• Web servers return content to clients
– a sequence of bytes with an associated MIME
(Multipurpose Internet Mail Extensions) type
• Example MIME types
– text/html HTML document
– text/plain Unformatted text
– application/postscript Postcript document
– image/gif Binary image encoded in GIF
format
– image/jpeg Binary image encoded in
JPEG format
Static & Dynamic Content
• The content returned in HTTP responses can be
either static or dynamic
– Static content: content stored in files and retrieved in
response to an HTTP request
• Examples: HTML files, images, audio clips
– Dynamic content: content produced on-the-fly in
response to an HTTP request
• 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
URLs
• 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 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
Anatomy of an HTTP Transaction
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.
HTTP/1.0 200 OK Server: response line
MIME-Version: 1.0 Server: followed by five response headers
Date: Mon, 08 Jan 2001 04:59:42 GMT
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
<html> Server: first HTML line in response body
... Server: 766 lines of HTML not shown.
</html> 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 by zero
or more request headers

• Request line: <method> <uri> <version>

– <version> is HTTP version of request (HTTP/1.0
or HTTP/1.1)
– <uri> is typically URL for proxies, URL suffix for
servers
– <method> is either GET, POST, OPTIONS,
HEAD, PUT, DELETE, or TRACE
HTTP Requests
• HTTP methods:
– GET: Retrieve static or dynamic content
• Arguments for dynamic content are in URI
• Workhorse method (99% of requests)
– POST: Retrieve dynamic content
• Arguments for dynamic content are in the request body
– OPTIONS: Get server or file attributes
– HEAD: Like GET but no data in response body
– 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:
• <version> <status code> <status msg>
– <version> is HTTP version of the response
– <status code> is numeric status
– <status msg> is corresponding English text
• 200 OK Request was handled without error
• 403Forbidden Server lacks permission to access file
• 404Not found Server couldn’t find the file
• Response headers: <header name>: <header data>
– 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
REST & HTTP
• The motivation for REST was to capture the
characteristics of the Web which made the Web
successful

– URI Addressable resources

– HTTP Protocol
– Make a Request – Receive Response – Display Response

• Exploits the use of the HTTP protocol beyond

HTTP POST and HTTP GET
– 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 in REST is a
resource

• A resource is a conceptual mapping to a set of entities

– Any information that can be named can be a 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.

• Represented with a global identifier (URI in HTTP)

– http://www.boeing.com/aircraft/747
Naming Resources
• REST uses URI to identify resources

– http://localhost/books/
– http://localhost/books/ISBN-0011
– http://localhost/books/ISBN-0011/authors

– http://localhost/classes
– http://localhost/classes/cs2650
– http://localhost/classes/cs2650/students

• As you traverse the path from more generic to more

specific, you are navigating the data
Verbs
• Represent the actions to be performed on
resources

• HTTP GET
• HTTP POST
• 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

• GET http://localhost/books
– Retrieve all books

• GET http://localhost/books/ISBN-0011021
– Retrieve book identified with ISBN-0011021

• GET http://localhost/books/ISBN-0011021/authors
– Retrieve authors for book identified with ISBN-0011021
HTTP PUT & POST
• HTTP POST creates a resource
• HTTP PUT updates a resource

• POST http://localhost/books/
– Content: {title, authors[], …}
– Creates a new book with given properties

• PUT http://localhost/books/isbn-111
– Content: {isbn, title, authors[], …}
– Updates book identified by isbn-111 with submitted properties
Representations
• How data is represented or returned to the client for
presentation.

• Two main formats:

– JavaScript Object Notation (JSON)

– XML

• It is common to have multiple representations of the

same data
Representations
• XML
<COURSE>
<ID>CS2650</ID>
<NAME>Distributed Multimedia Software</NAME>
</COURSE>

• 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 TCP as
transport protocol
• CoAP enables asynchronous communication
– 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
• Also supports multicast and congestion control
CoAP
What CoAP Is
• CoAP is
– A RESTful protocol
– Both synchronous and asynchronous
– For constrained devices and networks
– Specialized for M2M applications
– Easy to proxy to/from HTTP
BREAK
MQTT
• Message Queuing Telemetry Transport
• In a nutshell, MQTT consist of three parts:
– 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 embedded systems; now
shifting to IoT
• You can send anything as a message; up to 256
MB
• Built for unreliable networks
• Enterprise scale implementations down to hobby
projects
• Decouples readers and writers
• Message have a topic, quality of service, and retain
status associated 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.
Node.js Example
var mqtt = require('mqtt');
var client = mqtt.createClient('<<PortNumber>>', 'm11.cloudmqtt.com', {
username: '<<UserName>>’,
password: '<<Password>>'
});
client.on('connect', function () { // When connected
// 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

State Retention
• Publications
– Retained (“persistent” message)
• The subscriber upon first connection receives the last good
publication (i.e., does not have to wait for new publication)
– 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)
Publishing “QoS” (Reliability)
• 0 – unreliable (aka “at most once”)
– OK for continuous streams, least overhead (1
message)
– “Fire and forget”
– TCP will still provide reliability
Publishing “QoS” (Reliability)
• 1 – delivery “at least once” (duplicates possible)
– Used for alarms – more overhead (2 messages)
– Contains message ID (to match with ACKed message)
Publishing “QoS” (Reliability)
• 2 – delivery “exactly once”
– Utmost reliability is important – most overhead (4
messages) and slowest
Publishing “QoS” (Reliability)
• Reliability maintained even if the TCP
connection breaks (intermittent connections)
• Separate QoS for publishing and for subscribing
MQTT Message Format
Shortest Message is Two Bytes
Message Types
Message Types
Comparison CoAP & MQTT
Both used in IoT

• CoAP:
– one-to-one communication
– UDP/IP
– unreliable
– lightweight and easy to implement

• MQTT:
– many-to-many communication
– TCP/IP
– focus on message delivery; reliable
– higher overheads (protocol data, processing costs)
BREAK