COE 550: Internet of Things:

Applications and Implementation

Dr. Khaled Rabie

Computer Engineering Department

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 1

 Module 4: Connecting Smart Objects
(Part 1)

• IoT Networking Stack Options

• IoT Transport Layer
• Option 1: No Application Layer Protocol

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 2

Objectives
• To present the different protocol options to connect
smart devices.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 3

Road Map

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 4

Connectivity of Smart Objects
• Connectivity leverages great opportunities by allowing smart objects to:

Communicate with each other Communicate with the Cloud

• Request services • Store data on the cloud

• Send alerts • Request service from the
• Send actuating commands cloud
• Receive control commands
from the Cloud

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 5

IoT Architectural Connectivity
Cloud
• Various connectivity options in IoT:
• End devices:
G2C
• Directly (D2D) D2C
• Through Gateway (DGD) C2D
• Through Cloud (DCD) Gateway

• Device and Gateway:

• Gateway can aggregate devices data D2G G2D
and store it or send it to the cloud.
• Gateway can forward data between
devices. D2D
Device Device

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 6

IoT Heterogeneity Where is IoT?

Processing
• IoT systems are typically extermely
Heterogeneous.
• No two IoT applications have the
same requirements.
• So, we have to consider all options.
• Also, this makes designing each IoT
system a different challenge.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 7

Types of IoT Heterogeneity?

1. Heterogeneous devices
Sensors and actuators; microcontrollers and processors; edge devices
2. Heterogeneous communication protocols
3. Heterogeneous data formats
4. Heterogeneous cloud and edge computing platforms
5. Heterogeneous power sources

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 8

Network Architectures for IoT

• Existing TCP/IP protocols target media-rich

applications.
Application
• Most IoT applications communicate
simple sensor data. Network
• Two approaches have been proposed:
• Approach 1: Use TCP/IP stack but optimize Perception
the different protocols at the different layers.
• Approach 2: Use non-IP network, and enable
IP connectivity at the gatweay.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 9

Approach 1 Layer Generic IoT

• Use TCP/IP stack. Application HTTP CoAP, MQTT

• You can use generic
protocols if needed. But Transport TCP and UDP
normally require more
resources. Network IPv4 and IPv6 6LoWPAN

• IoT-specific protocols Data Link IEEE

are optimized for IoT 802.11ac, IEEE 802.11ah
applications and needs. Physical
Ethernet, BLE, IEEE 802.15.4
PLC
IEEE 802.15.4 defines the operation of a low-rate wireless personal area network (LR-WPAN).
IEEE 802.11ah (also known as WiFi Halow) is a new WiFi standard for sub-l GHz communications.
802.11ac is a Wi-Fi standard that delivers higher throughput to WLANs than 802.11n, the preceding Wi-Fi standard.
Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 10
Approach 2
Layer IoT
• Use IoT-specific DL/PHY ZigBee Application,
layers. LoRaWAN
Application ISA 100.11.a
App
• Use no-IP and IoT- WirelessHART
specific network and Network 6LoWPAN ZigBee
application layers.
• If you need IP, use Data Link LoRaWAN
6LoWPAN to help IEEE 802.15.4
optimize the IP Physical LoRa
overhead.
LoRa and LoRaWAN will be cover in details in this course.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 11

IP-enabled Devices
• A device that has layer 3 is called IP-enabled device.
• IP-enabled devices can talk to other devices using the IP protocol.
• If layer 3 is not available, the device cannot communicate directly
with other IP devices (cannot connect to the internet).
• One solution, is to use a gateway.
• Gateway is a device that translate between two protocols.

Non-IP
Non-IP device Gateway IP protocol IP device
Protocol

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation

Constrained Devices
• In RFC 7228, IETF acknowledges the following classes of constrained devices:

Characteristics
Class
Storage IP Example Technology

RAM < 10 KB
Class 0 No IP support Push Button (1 byte) No security
Flash < 100 KB
RAM > 10 KB
Class 1 Reduced IP support Smart Bracelet Some security
Flash > 100 KB
RAM < 50 KB
Class 2 Full IP stack Smart Power Meter Full Security
Flash < 250 KB

The Internet Engineering Task Force (IETF): A major standardization body, which released multiple RFCs on the topic of the IoT
Request For Comments (RFC): A formal standards-track document developed in working groups within the IETF

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 13

Constrained-Node Network
• Commonly referred to as Low-power Lossy Networks (LLNs).
• Characteristics of Constrained-Node Networks:
• Low data rates
• Lossy links (High error rate) → Frequent disconnections
• Interference (High density) → Reduced throughput
• Low power → Short range
• May not have full IP functionality → Reduced functions
• Data Rate vs. Throughput
• Throughput is usually much less that data rate due to header and control overhead.
• Understanding the above is key when designing IoT solutions.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 14

Constrained-Node Network – Cont.
• Many protocols have special futures that increase overhead when
enabled.
• Example: IEEE 802.15.4g (standard for smart metering utility networks)
Two-way
communication Data Rate
Modulation Frequency FEC
and variable (throughput)
payload size
OFF OFF 150 kbps
2 FSK 915 MHz ON OFF 75 kbps
ON ON 40-30 kbps

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 15

Constrained-Node Network – Cont.
• Uplink vs. Downlink
• Typically, IoT devices require higher data rate on the uplink than on the downlink.
• Latency and Determinism
• Data retransmissions result in latency that must be considered when selecting an
access technology.
• UDP is an appropriate choice for transport in such cases.
• Some technologies have special options for deterministic delivery.
• Overhead and Payload
• Lower layers use fragmentations of upper layers PDUs. Some, maximum payload size
must also be considered.
• For example, IPv6 MTU is 1280 bytes while IEEE 802.15.4 has a maximum payload of
127 bytes which demands fragmentation. While IEEE 802.15.4g enables payload of
2048 bytes which means no fragmentation is necessary.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation

Maximum Transmission Unit16(MTU)
Connection Oriented vs. Connectionless
Protocols can either be connection oriented or connectionless

Connection-Oriented: Connectionless:
• Establishes a connection before • No connection is established.
any data is sent. • Data is sent without getting
• Connection establishment and permission from the destination.
termination is always performed. • Requires less resources.
• Connection maintenance requires • Does not offer reliability but faster
resources. than connection oriented.
• Slower than connectionless but
offers reliability.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation

Transport Protocols
TCP UDP

• Connection-Oriented • Connectionless
• Session established before • No guarantee of delivery
exchange of data • No Acknowledgment
• Reliable • Analogy: Unregistered mail
• Acknowledged
• Analogy: Telephone call

The use of TCP is appropriate where data loss is unacceptable, for example, during authorization,
as well as when transmitting encrypted information.
Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 18
Transmission Control Protocol (TCP)
• Establishes a virtual circuit between hosts.
• Connection state needs to be maintained/tracked (stateful protocol). This is
very demanding for servers.
• Virtual circuit is established with a 3-way handshake. You remember this?
• Features:
• Reliability: delivered packets are acknowledged by the receiver.
• Flow control: TCP uses window size to control the number of packets sent at a time
to prevent buffer overflow at the receiver.
• The TCP window size field controls the flow of data and is limited to 2 bytes.
• Or a window size of 65,535 bytes.
• Congestion control: If congestion is detected (dropped packets at switches), TCP
reduces transmission speed (reduce window size).
• TCP is by far the dominant transport protocol used in the [Link]
Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 19
 Transmission Control Protocol (TCP) – Cont.

• Advantages:
• Transports large volume of data
• Guaranteed and ordered delivery Initiate TCP
connection
• Flow control and sliding window RTT
• Retransmission of lost packets
Request file
• Disadvantages: Time to
RTT
• High overhead transmit
file
• High latency File received
• Suitable for application with large data size
and high reliability, and no delay requirements. time time
• Applications: HTTP, Email, FTP, etc. Round Trip Time (RTT)
File Transfer Protocol (FTP)
Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 20
Hypertext Transfer Protocol (HTTP)
User Datagram Protocol (UDP)

• No connection is established before transmission (connectionless).

• No Connection state needs to be maintained (stateless protocol).
• Best effort protocol (no reliability assurance).
• Reliability can be implemented at the application layer instead.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 21

User Datagram Protocol (UDP) – Cont.
• Advantages:
• No connection setup required
• Low overhead
• Low latency

• Disadvantages:
• Unordered delivery
• Unguaranteed delivery
• No error control
• Suitable for application with small data size and low reliability requirements and
delay-sensitive.
• UDP fits IoT applications because it usually involves a server serving a large number
of clients that send small amounts of data.
• Applications: Network services such as DNS, NTP, DHCP, delay-sensitive applications.

Domain
Dr. name
Khaled Rabie system (DNS); NetworkCOE
Time
550 -Protocol (NTP);
IoT: Applications Dynamic Host Configuration Protocol (DHCP)22
and Implementation
TCP vs. UDP Header
• TCP wraps each data packet with a
header containing 10 mandatory
fields totaling 20 bytes (or octets).
• Each header holds information about
the connection and the current data
being sent.
• TCP header is 20 bytes minimum
and can grow up to 40 bytes with
options.
• UDP 8 bytes only.
• If IoT data to be sent is very small,
the overhead may be significant.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 23

TCP vs. UDP Header – Cont.
• Source port – The sending device’s port.
• Destination port – The receiving device’s port.
• Sequence number – A device initiating a TCP connection must
choose a random initial sequence number, which is then
incremented according to the number of transmitted bytes.
• Acknowledgment number – The receiving device maintains an
acknowledgment number starting with zero. It increments this
number according to the number of bytes received.
• Header length – This specifies the size of the TCP header, expressed
in 32-bit words. One word represents four bytes.
• Reserved data – The reserved field is always set to zero.
• Control flags – TCP uses nine control flags to manage data flow in
specific situations, such as the initiating of a reset.
• Window size TCP checksum – The sender generates a checksum
and transmits it in every packet header. The receiving device can
use the checksum to check for errors in the received header and
payload.
• Urgent pointer – If URG control flag is set, this value indicates an
offset from the sequence number, indicating the last urgent data
byte.
• Optional data – These are optional fields for setting maximum
segment sizes, selective acknowledgments and enabling window
scaling for more efficient use of high-bandwidth networks.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 24

The Choice of Transport Protocols for IoT
• In Internet traffic, TCP is the dominant protocol by far:
• Many industrial applications use TCP since they are old and were built over
unreliable data-link layers.
• TCP requires the establishment of a logical connection and has more
overhead in software.
• Maintaining thousands of TCP connections over large IoT system is costly.
• UDP is more appealing for IoT because of the low overhead,
especially if the data is very small.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 25

The Choice of Transport Protocols for IoT – Cont.
• Because of the unreliable links in LLN, maintaining a logical link over
such networks may not be always possible. When is TCP/UDP better?

TCP is better when UDP is better when

• Data is large • Data is small
• Link setup/maintenance
cost is low. • Link establishing/
• High latency can be
maintenance cost is high.
tolerated. • Low latency is required.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 26

 Design Considerations for Application Protocols for IoT

• The limited-resources nature of IoT devices calls for lightweight non-computation-

intensive protocols.
• IoT data is generally small, so protocol overhead should be minimal.
• Data link layer frame size is small, application layer PDU should be small to avoid
fragmentation which causes delay and multiple transmissions (more energy
consumption).
• IoT devices sleep frequently, so connectionless protocols is preferred to avoid
frequent reestablishment of connections for connection-oriented protocols.
• Connection-oriented protocols keep connection alive which could drain the battery.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 27

 IoT Application Protocols

Option 1 Option 2 Option 3

No Application Layer Generic Web-based IoT Application

Protocols
• Application data is
Layer Protocols
injected into • HTTP
transport/Network/MAC • Used for • MQTT
layer frame. unconstrained IoT • CoAP

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 28

Option 1: No Application Layer Protocol

• Application layer protocols come with TCP or UDP header IoT Data
their own overhead. Transport Header Payload
• If the IoT data does not benefit from the
application layer protocol, it can be IPv4 or IPv6 header IoT Data
abended. Network Header Payload
• Note:
LoRaWAN or BLE header IoT Data
• The receiving layer must also be changed.
Data Link Header Payload
• May not be compatible with other systems.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 29

Option 1.1: Transport Layer
An example of using the transport layer TCP/UDP to carry IoT data without
application layer protocol

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 30

import socket
# Server IP
HOST =‘localhost'
# Server PORT
PORT = 45000
# Buffer Size
BUF_SIZE = 1024

s = [Link](socket.AF_INET, socket.SOCK_STREAM) # initialize a socket object

[Link]((HOST,PORT)) # register port with OS

print("I am waiting for a client ...")

[Link](1) # wait for a connection (maximum of 1 connection)

# accept connection and retrieve conn object and address

conn, add = [Link]()
print("I got a connection form ",add)

while True:

[Link]
data = [Link](BUF_SIZE).decode() # check if data accepted
if not data: # no data, pass
break
print('I received '+ str(data))
data=str(data).upper() # convert data to upper case

[Link]([Link]()) # send data back

# close connection
[Link]() COE 550 - IoT: Applications and Implementation 31
import socket
HOST ='localhost' # Server IP

PORT = 45000 # Server PORT

BUF_SIZE = 1024 # Buffer Size

message = "Hi there!”

# initialize a socket object

s = [Link](socket.AF_INET,socket.SOCK_STREAM)
# connect to server
[Link]((HOST,PORT))

[Link]([Link]()) # send message

data = [Link](BUF_SIZE).decode() # wait to receive a message

[Link]
print('received: '+ str(data))
[Link]() # close connection

print("Bye")

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 32

import socket
HOST =‘localhost' # Server IP

PORT = 45000 # Server PORT

BUF_SIZE = 1024 # Buffer Size

s = [Link](socket.AF_INET, socket.SOCK_DGRAM)
# initialize a socket object
[Link]((HOST,PORT))
# register port with OS
print("I am waiting for a client ...")

while True: # wait for a connection

data, addr = [Link](BUF_SIZE) # accept connection and retrieve conn object and address

[Link]
data = [Link]() # Process the received data

print('I received '+ str(data)+ ' from ',addr)

data=str(data).upper() # convert data to upper case
# send data back
[Link]([Link](), addr)

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 33

import socket # Server IP
HOST ='localhost' # Server PORT

PORT = 45000 # Buffer Size

BUF_SIZE = 1024
message = "Hi there!”

# initialize a socket object

s = [Link](socket.AF_INET, socket.SOCK_DGRAM)
# send message
[Link]([Link](), (HOST,PORT))

data = [Link](BUF_SIZE) # wait to receive a message

print('received '+ str([Link]()))
print("Bye")

[Link]
Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 34
Option 1.2: Data-Link Layer
An example of using the Data Link layer LoRaWAN to carry IoT data without
Application Protocol, Transport, or IP layers.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 35

LoRaWAN frame as IoT Data Container
• Class 0 of IETF RFC 7228 (extremely constrained) do not implement a full
IP, TCP, or UDP stacks, or even an application layer protocol.
• Example: Low-cost temperature and humidity sensor over LoRaWAN
• Temperature is represented as 2B and humidity as 2B (small payload).
• It can be injected directly in the payload of LoRaWAN MAC frame (without the
use of TCP/IP).
• Complexity of decoding can be pushed to the application layer at the server.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 36

Data Broker: Standardization and Compatibility
• In the OSI model, the presentation
layer is responsible for data formats.
• Today, presentation is part of
application layer protocols.
• A big disadvantage with this approach
is the lack of standardization in
formats and consequently
interoperability issues.
• One solution is to use a “Data Broker”
to translate and standardize different
data formats.
Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 37
Example: How Much to Save with no App Layer
Assume a sensor generates temperature readings between -20 and 60 Co.
Consider the case of using HTTP vs. the case with no application layer
protocol. Answer the following questions:
1) What is the frame size in each case? Assume WiFi is used.
The number of values to
represent is 60- (-20) = 80. Layer With HTTP (bytes) No Application (bytes)
Sensor Data
The minimum size would
then be log 2 80 = Application 100 0
7 𝑏𝑖𝑡𝑠 ≈ 1 𝑏𝑦𝑡𝑒. Transport 20 20
Note: Most computers are Network 20 20
byte-addressable so the Data Link 34 34
minimum data size they use
is a byte. Total

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 38

Example #1: How Much to Save with no App Layer
Assume a sensor generates temperature readings between -20 and 60 Co.
Consider the case of using HTTP vs. the case with no application layer
protocol. Answer the following questions:
1) What is the frame size in each case? Assume WiFi is used.
The number of values to
represent is 60- (-20) = 80. Layer With HTTP (bytes) No Application (bytes)
Sensor Data 1 1
The minimum size would
then be log 2 80 = Application 100 0
7 𝑏𝑖𝑡𝑠 ≈ 1 𝑏𝑦𝑡𝑒. Transport 20 20
Note: Most computers are Network 20 20
byte-addressable so the Data Link 34 34
minimum data size they use
is a byte. Total 175 75

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 39

Example #1 – Cont.
2) What is the total extra overhead if the network has 5,000 sensors?
• Using the results from the table:
Overhead = 5,000 packets * (175-75) byte = 500,000 B (0.5 MB)
3) How much extra data (in bps) is needed to implement HTTP compared to
No HTTP, if each sensor sends 1 packet per second?
• The aggregated overhead traffic will be
Overhead data rate = (500,000 x 8 bits)/(1 second) = 4 Mbps.

Compare this to LoRaWAN network that has a maximum data rate of 50 kbps!

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 40

Exercise (Based on Example #1)

• How much is the total extra overhead if the network has 25,000 sensors?
Use the results from the previous table.

• How much extra data is needed to implement HTTP compared to No

HTTP, if each sensor sends 2 packet per second?

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 41

Exercise (Based on Example #1)

• How much is the total extra overhead if the network has 25,000 sensors?
Use the results from the previous table.
Overhead = 25,000 packet * (175-75) byte = 2.5 MB

• How much extra data is needed to implement HTTP compared to No

HTTP, if each sensor sends 2 packet per second?
Overhead data rate = (2,500,000 x 16 bits)/(1 second) = 40 Mbps.

Dr. Khaled Rabie COE 550 - IoT: Applications and Implementation 42