CHAPTER 3

P.2. IOT PROTOCOLS

AND CONECTIVITY

PhD. Cao Van Kien

[email protected]
CONNECTING ALL THE THINGS IN THE
INTERNET OF THINGS ?
OUTLINE
1. IoT protocol

2. IoT data link protocols

3. Network layer routing protocol

4. Network layer encapsulation protocols

5. Session Layer Protocols

6. IoT networking considerations and challenges

1. IOT PROTOCOLS

How IoT
IoT devices communicate using IoT protocols
devices
communicate
with the IoT protocols ensure that information from one device or
network? sensor gets read and understood by another
E.g. Internet protocol (IP) is a set of rules that dictates how data gets
sent to the internet

What IoT Each protocol in the IoT system architecture enables

protocol is device-to-device, device-to-gateway, gateway-to-data
right for me? center, or gateway-to-cloud communication, as well as
communication between data centers
1. IOT PROTOCOLS
HTTP MQTT CoAP XMPP
Application
layer
WebSocket DDS AMQP

Transport
TCP UDP
layer

Network layer IPv4 IPv6 6LOWPAN

802.16 - 802.15.4- 2G/3G/4G/ IEEE

WiMax LR-WPAN 5G 802.15.4

Link layer 802.3- 802.11-

Bluetooth LoRaWAN
Ethernet WiFi

Zigbee Z-wave Dash7 …

2. IOT DATA LINK LAYER PROTOCOLS

Low-Power
Wide-Area Short-Range
Network Wireless
(LPWAN) Technologies
Technologies

Cellular Satellite
technologies technologies
Wire/wireless communication
technologies

Range of communication technologies

2. IOT DATA LINK LAYER PROTOCOLS
Wireless - Short-Range Solutions

Short-range IoT connectivity solutions transfer data over small physical

distances usually less than 150 meters.

Typical fields of IoT applications for shortrange connectivity solutions are

wearables and smart waste management in smart city ecosystems, as the
distances between the 'things' and the next gateway are usually very short.
2. IOT DATA LINK LAYER PROTOCOLS
Wireless - Short-Range Solutions
Power
Max.
Solution Frequency Max. range Latency Topology consumptio
Throughput
n

Wi-Fi (IEEE Various (sub

100 m 40 Mbps 100 ms Mesh Low
802.11ah) - 1 GHz)

Bluetooth
2.4 GHz 100 m 2 Mbps 6 ms Point to point Low
low energy

800-900
Z-wave 100 m 100 kbps NA Mesh Low
MHz

Zigbee 2.4 GHz 100 m 250 kbps 10 ms Mesh Low

NFC 13.56 MHz 10 cm 424 kbps 100 ms Point to point Low

2. IOT DATA LINK LAYER PROTOCOLS
Wireless - Long-Range Solutions Cellular

Cellular provides solutions for IoT solutions that require long-distance data
transfers combined with low latency.

Advantage Cellular
• Sending high quantities of data
• Provide the low power, low throughput.
• The lower prices charged by mobile network operators.
2. IOT DATA LINK LAYER PROTOCOLS
Wireless - Long-Range Solutions
Power
Max.
Solution Frequency Max. range Latency Topology consumptio
Throughput
n

GMS/GPRS 384 kbps 0.15 – 1s High

LTE CAT 1 10 Mbps 0.05 – 0.1 s Medium

Various
LTE CAT 0 (Depending Up to 100 km 1 Mbps NA Star Medium
region)
LTE CAT
250 kbps 1.6 – 10s Low
NB1 (NBIoT)

LTE CAT M1
1 Mbps 10-15 ms Low
(eMTC)
2. IOT DATA LINK LAYER PROTOCOLS
Wireless - Long-Range Solutions LPWAN

The term LPWAN is made up out of two sub-terms:

• Low Power (LP) means that the hardware power consumption is generally
very low and therefore can operate on small, inexpensive batteries for
several years.
• Wide Area Network (WAN) indicates that the connectivity solution can bridge
an operating range that is typically more than 10 km in urban areas.

It is important to understand that LPWAN itself is not a connectivity standard, but rather an
umbrella term encompassing various implementations and protocols that share common
connectivity characteristics
2. IOT DATA LINK LAYER PROTOCOLS
Wireless - Long-Range Solutions - LPWAN

Max. Power
Solution Frequency Max. range Topology
Throughput consumption

Various (sub - 1
LoraWAN 15 km 50 kbps Star Very Low
GHz)

10 kbps
Sigfox 900 MHz 50 km Star Very Low

Various (sub - 1
Weighless 5 km 10 Mbps Star Very Low
GHz)

Various (sub - 1
Ingenu 1500 km 38 kbps Star Very Low
GHz)
2. IOT DATA LINK LAYER PROTOCOLS
Wire Solutions
Wired solutions are applied when a) the 'thing', for example a machine, usually stays at the
same location and there is no need for mobility, and b) the distance between the sensor and the
gateway is short.

These solutions are usually aimed at broadband applications, such as in-home distribution of
IPTV, Internet connectivity, and smart grids, where data is transferred through the existing
electrical wires installed within the building.
2. IOT DATA LINK LAYER PROTOCOLS
Wire Solutions
Overview of current wired connectivity solutions
3. NETWORK LAYER ROUTING PROTOCOL
Routing layer handles the transfer the packets from source to destination.

 RPL
 IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) is
designed for routing IPv6 traffic over low-power networks like those
networks implemented over 6LoWPAN.
 RPL (pronounced “ripple”) is designed for routing packets within constrained
networks such as wireless sensor networks, where not all devices are
reachable at all times and where there are high or unpredictable amounts of
packet loss.
 RPL can compute the optimal path by building up a graph of the nodes in
the network based on dynamic metrics and constraints like minimizing
energy consumption or latency.
3. NETWORK LAYER ROUTING PROTOCOL
 CoRPL
 An extension of RPL is CORPL, or cognitive RPL, which is designed for
cognitive networks and uses Destination Oriented Directed Acyclic Graph
(DODAG) topology generation but with two new modifications to RPL.
 CORPL utilizes opportunistic forwarding to forward the packet by choosing
multiple forwarders (forwarder set) and coordinates between the nodes to
choose the best next hop to forward the packet to.
 DODAG is built in the same way as RPL. Each node maintains a forwarding
set instead of its parent only and updates its neighbor with its changes using
DIO messages. Based on the updated information, each node dynamically
updates its neighbor priorities in order to construct the forwarder set.
3. NETWORK LAYER ROUTING PROTOCOL
 CARP
 Channel-Aware Routing Protocol (CARP) is a distributed routing protocol
designed for underwater communication. It can be used for IoT due to its
lightweight packets.
 It considers link quality, which is computed based on historical successful
data transmission gathered from neighboring sensors, to select the
forwarding nodes.
 There are two scenarios: network initialization and data forwarding.
o In network initialization, a HELLO packet is broadcasted from the sink to
all other nodes in the networks.
o In data forwarding, the packet is routed from sensor to sink in a hop- by-
hop fashion. Each next hop is determined independently.
3. NETWORK LAYER ROUTING PROTOCOL
 CARP
 The main problem with CARP is that it does not support reusability of
previously collected data.
 In other words, if the application requires sensor data only when it changes
significantly, then CARP data forwarding is not beneficial to that specific
application. An enhancement of CARP was done in E-CARP by allowing the
sink node to save previously received sensory data. When new data is
needed, E-CARP sends a Ping packet which is replied with the data from
the sensor nodes. Thus, E-CARP reduces the communication overhead
drastically.
3. NETWORK LAYER ROUTING PROTOCOL
Summary
 RPL is the most commonly used one. It is a distance vector protocol
designed by IETF in 2012.
 CORPL is a non-standard extension of RPL that is designed for cognitive
networks and utilizes the opportunistic forwarding to forward packets at
each hop.
 On the other hand, CARP is the only distributed hop based routing protocol
that is designed for IoT sensor network applications. CARP is used for
underwater communication mostly.
3. NETWORK LAYER ROUTING PROTOCOL

 IPv6
 At the Internet Layer, devices are identified by IP addresses.
 IPv6 is typically used for IoT applications over legacy IPv4 addressing.
 IPv4 is limited to 32-bit addresses, which only provide around 4.3 billion
addresses in total, which is less than the current number of IoT devices
that are connected, while IPv6 uses 128 bits, and so provides
2 128 addresses (around 3.4 C 10 38 or 340 billion billion billion billion)
addresses.
4. NETWORK LAYER ENCAPSULATION PROTOCOLS
One problem in IoT applications is that IPv6 addresses are too long and cannot
fit in most IoT datalink frames which are relatively much smaller. Hence, IETF is
developing a set of standards to encapsulate IPv6 datagrams in different datalink
layer frames for use in IoT applications.
 6LoWPAN
 The IPv6 Low Power Wireless Personal Area Network
(6LoWPAN) standard allows IPv6 to be used over 802.15.4 wireless
networks.
 6LoWPAN is often used for wireless sensor networks, and
the Thread protocol for home automation devices also runs over
6LoWPAN.
4. NETWORK LAYER ENCAPSULATION PROTOCOLS
 6LoWPAN
 It efficiently encapsulates IPv6 long headers in IEEE802.15.4 small
packets, which cannot exceed 128 bytes.
 The specification supports different length addresses, low bandwidth,
different topologies including star or mesh, power consumption, low cost,
scalable networks, mobility, unreliability and long sleep time.
 The standard provides header compression to reduce transmission
overhead, fragmentation to meet the 128-byte maximum frame length in
IEEE802.15.4, and support of multi-hop deliver.
4. NETWORK LAYER ENCAPSULATION PROTOCOLS
 6TiSCH
 6TiSCH working group in IETF is developing standards to allow IPv6 to
pass through Time Slotted Channel Hopping (TSCH) mode of IEEE
802.15.4e datalinks.
 It defines a Channel Distribution usage matrix consisting of available
frequencies in columns and time-slots available for network scheduling
operations in rows.
 The standard does not specify how the scheduling can be done and
leaves that to be an application specific problem in order to allow for
maximum flexibility for different IoT applications. The scheduling can be
centralized or distributed depending on application or the topology used
in the MAC layer.
4. NETWORK LAYER ENCAPSULATION PROTOCOLS
 6TiSCH
 6TiSCH working group in IETF is developing standards to allow IPv6 to
pass through Time Slotted Channel Hopping (TSCH) mode of IEEE
802.15.4e datalinks.
 It defines a Channel Distribution usage matrix consisting of available
frequencies in columns and time-slots available for network scheduling
operations in rows.
 The standard does not specify how the scheduling can be done and
leaves that to be an application specific problem in order to allow for
maximum flexibility for different IoT applications. The scheduling can be
centralized or distributed depending on application or the topology used
in the MAC layer.
4. NETWORK LAYER ENCAPSULATION PROTOCOLS
 IPv6
 At the Internet Layer, devices are identified by IP addresses.
 IPv6 is typically used for IoT applications over legacy IPv4 addressing.
 IPv4 is limited to 32-bit addresses, which only provide around 4.3 billion
addresses in total, which is less than the current number of IoT devices
that are connected, while IPv6 uses 128 bits, and so provides
2 128 addresses (around 3.4 C 10 38 or 340 billion billion billion billion)
addresses.
4. NETWORK LAYER ENCAPSULATION PROTOCOLS
 IPv6 over G.9959
 RFC 7428 defines the frame format for transmitting IPv6 packet on ITU-T
G.9959 networks.
 G.9959 defines a unique 32-bit home network identifier that is assigned
by the controller and 8- bit host identifier that is allocated for each node.
 An IPv6 link local address must be constructed by the link layer derived
8-bit host identifier so that it can be compressed in G.9959 frame.
 Furthermore, the same header compression as in 6lowPAN is used here
to fit an IPv6 packet into G.9959 frames.
 RFC 7428 also provides a level of security by a shared network key that
is used for encryption.
4. NETWORK LAYER ENCAPSULATION PROTOCOLS
 IPv6 over Bluetooth Low Energy
 Bluetooth Low Energy is also known as Bluetooth Smart and was
introduced in Bluetooth V4.0 and enhanced in V4.1.
 RFC 7668 [RFC7668], which specifies IPv6 over Bluetooth LE, reuses
most of the 6LowPAN compression techniques.
 However, since the Logical Link Control and Adaptation Protocol
(L2CAP) sublayer in Bluetooth already provides segmentation and
reassembly of larger payloads in to 27 byte L2CAP packets,
fragmentation features from 6LowPAN standards are not used.
 Another significant difference is that Bluetooth Low Energy does not
currently support formation of multi-hop networks at the link layer.
Instead, a central node acts as a router between lower-powered
peripheral nodes.
5. APPLICATION LAYER PROTOCOLS

 MQTT
 Message Queue Telemetry Transport (MQTT) is a publish/subscribe-
based messaging protocol that was designed for use in low bandwidth
situations, particularly for sensors and mobile devices on unreliable
networks.

 AMQP
 Advanced Message Queuing Protocol (AMQP) is an open standard
messaging protocol that is used for message-oriented middleware. Most
notably, AMQP is implemented by RabbitMQ.
5. APPLICATION LAYER PROTOCOLS

 XMPP
 The Extensible Messaging and Presence Protocol (XMPP) was originally
designed for real-time human-to-human communication including instant
messaging.
 This protocol has been adapted for machine-to-machine (M2M)
communication to implement lightweight middleware and for routing XML
data. XMPP is primarily used with smart appliances.
 5. APPLICATION LAYER PROTOCOLS
APPLICATION LAYER

Protocol CoAP XMPP RESTful HTTP MQTT

Transport UDP TCP TCP TCP
Messaging Request/ Publish/Subscribe Request/Response Publish/Subscribe
Response Request/Response Request/Response
2G, 3G, 4G Excellent Excellent Excellent Excellent
LLN Excellent Fair Fair Fair
Suitability
Compute 10Ks 10Ks RAM/Flash 10Ks RAM/Flash 10Ks RAM/Flash
Resources RAM/Flash
Success Utility Field Remote Smart Energy Extending
Stories Area Networks management of enterprise
consumer white messaging into IoT
goods applications
5.1. MQTT PROTOCOL

5.1.1. Giới thiệu

5.1.2. Các thành phần cơ bản giao thức MQTT
5.1.3. Định dạng của message/ cấu trúc bức điện
 Phần hearder cố định
 Phần header có độ dài thay đổi được
 Payload
 Message identifiers
 UTF-8
 Unused bits
 Command messages
5.1.4. Mosquitto MQTT Messaging Broker
 5.1.1. MQTT PROTOCOL – GIỚI THIỆU

MQTT : Message Queuing Telemetry Transport

MQTT là một giao thức gởi dạng publish/subscribe sử dụng cho các thiết
bị Internet of Things với băng thông thấp, độ tin cậy cao và khả năng được sử
dụng trong mạng lưới không ổn định.
MQTT sử dụng băng thông thấp trong môi trường có độ trễ cao nên nó là một
giao thức lý tưởng cho các ứng dụng M2M.
5.1.2. CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC MQTT
MQTT Components?

 Broker, which is the server that handles the data transmission between the clients.
 A topic, which is the place a device want to put or retrieve a message to/from.
 The message, which is the data that a device receives “when subscribing” from a topic or
send “when publishing” to a topic.
 Publish, is the process a device does to send its message to the broker.
 Subscribe, where a device does to retrieve a message from the broker.
 5.1.2. CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC MQTT

Broker: là server cài MQTT, server thu thập dữ liệu và giao tiếp các client.

Topic: Là chủ đề mà Broker tạo ra để Device gửi vào. Nó như là folder chứa dữ
liệu vậy nên có thể ở dạng đường dẫn abc/topic1.

Publish: Là gói tin Device gửi lên Broker. Khi Device Publish dữ liệu vào topic,
các Client sẽ nhận được dữ liệu khi đăng kí topic. Gói Publish có thể là gói gửi dữ
liệu gửi vào topic hoặc gói cài đặt Retain Message hay LWT Message do cờ
Retain, LWT quy định

Subscribe: Là gói đăng kí nhận data hay thông tin từ topic đăng kí (Broker sẽ
tạo một topic mới nếu không tìm được topic đăng kí). Khi Client gửi gói tin
Subcribe tới Broker để đăng kí một topic, ví dụ topic “T2Tdemo”. Bất cứ khi nào
Device gửi gói tin Publish vào topic “T2Tdemo”. Dữ liệu trong gói Publish
chuyển về Client. Giống như bạn Subscribe youtube
 5.1.2. CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC MQTT
Qos: Chất lượng đường truyền

 Qos 0: Device gửi Publish tới Server không cần quan tâm đến gói tin gửi.

 Qos 1: Device gửi Publish tới Server ,Sau đó nếu Server nhận được gói tin và gửi lại
Device gói PUBACK để xác nhận đã nhận được gói Publish từ Device

 Qos 2: Device gửi Publish tới Server , Server nhận gói Publish gửi PUBREC lại Device
kèm theo ID đã nhận. Device nhận PUBREC gửi PUBREL kèm ID đó lại Server. Server
gửi lại PUBCOMP lại Device.
 5.1.2. CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC MQTT

Retain: Là cờ báo gói Publish, Device gửi tới Broker cài đặt Retain Message
cho topic. Khi Client subcribe vào topic đã cài đặt Retain Message sẽ nhận
được ngay Retain Message. Ví dụ “Device online”.

LWT(Last Will and Testament):Là cờ báo gói Publish, Device gửi tới Broker
topic cài đặt LWT Message. Khi Client Subcribe vào topic đã cài đặt LWT
Message sẽ nhận được tin nhắn LWT Message khi Device offline
5.1.2. CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC MQTT
How MQTT works?

When a device (a client) wants to send data to the broker, we call this operation
a “publish”.

When a device (a client) wants to receive data from the broker, we call this
operation a “subscribe”.
 5.1.2. CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC MQTT
How MQTT works?

Examples: Monitoring the temperature

Let’s say there is a device that has a temperature sensor. Certainly, it wants to send his
readings to the broker. On the other side, a phone/desktop application wants to receive this
temperature value. Therefore, 2 things will happen:
 The device defines the topic it wants to publish on, ex: “temp”. Then, it publishes the
message “temperature value”.
 The phone/desktop application subscribes to the topic “temp”. Then, it receives the message
that the device has published, which is the temperature value.
 Again, the broker role here is to take the message “temperature value” and deliver it to
phone/desktop application.
 5.1.2. CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC MQTT

Có bao nhiêu thiết bị có thể kết nối vào MQTT broker?

The number of connected devices “clients” to the broker depends on

the broker service provider
5.1.3. ĐỊNH DẠNG CỦA MESSAGE/ CẤU TRÚC BỨC ĐIỆN

MQTT message format – xem thêm tài liệu để thực hành LAB
 PHẦN HEADER CỐ ĐỊNH
bit 7 6 5 4 3 2 1 0
byte 1 Loại Message Cờ QoS level RETAIN
byte 2 Độ dài còn lại

Byte 1: Chứa loại Message và các cờ (DUP, QoS level, and RETAIN)

Byte 2: Quy định độ dài còn lại (Ít nhất 1 tức là 1 byte)
 PHẦN HEADER CỐ ĐỊNH
Loại Message: Byte 1, bits 7-4.
Từ gợi nhớ Giá trị thứ tự Miêu tả
Reserved 0 Chưa dùng
CONNECT 1 Client yêu cầu kết nối đến Server
CONNACK 2 Kết nối được chấp nhận
PUBLISH 3 Xuất bản message
PUBACK 4 Xuất bản message được chấp nhận
PUBREC 5 Xuất bản đã được nhận (đảm bảo nhận được part 1)
PUBREL 6 Xuất bản release (đảm bảo nhận được part 2)
PUBCOMP 7 Xuất bản hoàn thành (đảm bảo nhận được part 3)
SUBSCRIBE 8 Yêu cầu subcribe từ client
SUBACK 9 Yêu cầu subcriber được chấp nhận
UNSUBSCRIBE 10 Yêu cầu unsubcribe
UNSUBACK 11 Yêu cầu unsubcribe được chấp nhận
PINGREQ 12 Request PING
PINGRESP 13 Response PING
DISCONNECT 14 Client đang mất kết nối
Reserved 15 Reserved
 PHẦN HEADER CỐ ĐỊNH
Các cờ: Các bit còn lại của byte đầu tiên tương ứng sẽ mô tả trạng thái của DUP, QoS và RETAIN
DUP: byte 1, bit 3.

 Cờ này được bật khi client hoặc server đang cố chuyển lại một gói PUBLISH, PUBREL,
SUBSCRIBE or UNSUBSCRIBE. Giá trị này được sử dụng trong các mesage mà có QoS
lớn hơn 0 và yêu cầu ACK. Khi bit DUP được set, phần header thay đổi sẽ là Message ID.

 Phía nhận xem giá trị này là một gợi ý để tự kiểm tra xem gói tin (có Message ID) ở trên đã
chuyển đến trước đó hay không. Còn chỉ từ trạng thái cờ DUP này thì chưa thể chắc chắn
có gói tin lặp được.

QoS: byte 1, bits 2-1. Cờ này sẽ cho biết mức độ tin cậy của việc chuyển message PUBLISH.

Giá trị QoS bit 2 bit 1 Miêu tả

0 0 0 Cùng lắm là 1 lần Gửi rồi quên ngay <=1
1 0 1 Ít nhất 1 lần Xác nhận bằng ACK >=1
2 1 0 Chính xác 1 lần Nhận đảm bảo =1
3 1 1 Chưa dùng
 PHẦN HEADER CỐ ĐỊNH
Các cờ: Các bit còn lại của byte đầu tiên tương ứng sẽ mô tả trạng thái của DUP, QoS và RETAIN

RETAIN: byte 1, bit 0.

 Cờ này chỉ được sử dụng ở message PUBLISH.
 Khi client gửi 1 message PUBLISH đến server, nếu cờ Retain được set (1), thì server phải
hiểu rằng phải giữ message này sau khi chuyển nó đến các subcribers hiện tại.
 Khi có 1 subcription (yêu cầu nhận tin từ subscriber) mới được thiết lập đến 1 topic,
message cuối cùng được lưu lại của topic đó phải được gửi đến subscriber và trường
Retain được set (1) trong phần header. Nếu không có messsage nào của topic được lưu
giữ, thì không cần gửi gì hết.
 Trường hợp mà server chuyển tiếp nội dung vừa nhận được từ một Publisher thì trường
Retain sẽ không được set. Điều này sẽ giúp phân biệt được message có từ trước với
message mới được publish lên.
 Message Retained sẽ được giữ thậm chí sau khi restart lại server
 Server sẽ xóa message được retained nếu nó nhận đựoc một message với payload bằng
zero.
 PHẦN HEADER CỐ ĐỊNH
Byte 2: Quy định độ dài còn lại
 Miêu tả độ dài bao gồm cả phần header và payload có trong message.
 Việc mã hóa với độ dài thay đổi sử dụng 1 byte để miêu tả độ dài, vì thế độ dài tối đa
sẽ là 127.
 Những message dài hơn sẽ được miêu tả: 7 bít được dùng để miêu tả giá trị, bít còn
lại dùng để miêu tả phía sau còn byte nào miêu tả trường này hay không.
 Mỗi byte tiếp sau đó cũng như vậy 7 bit để lưu giá trị, 1 bít gọi là bit tiếp tục.

Bảng mô tả độ dài có thể biểu diễn với các số byte tương ứng
Số byte Độ dài min Độ dài max
1 0 (0x00) 127 (0x7F)
2 128 (0x80, 0x01) 16 383 (0xFF, 0x7F)
3 16 384 (0x80, 0x80, 0x01) 2 097 151 (0xFF, 0xFF, 0x7F)

4 2 097 152 (0x80, 0x80, 0x80, 0x01) 268 435 455 (0xFF, 0xFF, 0xFF, 0x7F)
 PAYLOAD

CONNECT: Chứa một hoặc nhiều chuỗi UTF-8 encoded. Trong đó, chỉ định rõ một identifier duy
nhất cho client, một Will topic and message and và cả user name, password nữa.

SUBSCRIBE: Chứa một danh sách các topic name mà client có thể subcribe và cả QoS level nữa.
Tất cả chúng cũng là UTF-encoded.

SUBACK: Payload sẽ chưa một danh sách của các QoS level được cho phép. Có một mức QoS
level mà administrators của server cho phép client sử dụng để subcribe đến một Topic name cụ thể.
Những QoS level này được liệt kê cùng thứ tự tương ứng với danh sách các Topic Name trong
message SUBSCRIBE.

Phần payload của message PUBLISH chỉ chứa dữ liệu cho ứng dụng cụ thể. Không thể giả định
chúng được tạo bởi dữ liệu tự nhiên hay nội dung của dữ liệu, phần này sẽ được hiểu là một BLOB.

Nếu bạn muốn ứng dụng thực hiện việc nén dữ liệu đưa vào trong payload data, bạn cần định nghĩa
trong ứng dụng một cờ payload tương ứng để xử lý nhưng dữ liệu payload này. Bạn không thể định
nghĩa một cờ chỉ cho ứng dụng cụ thể bên trong bất cứ thành phần nào của header.
 MESSAGE IDENTIFIERS

Message identifier được xuất hiện trong phần header của các message dưới đây:
PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK,
UNSUBSCRIBE, UNSUBACK.
Message Identifier (Message ID) chỉ xuất hiện trong message khi giá trị QoS bit
miêu tả trong header chỉ định đến giá trị QoS 1 hoặc 2.
Message ID là một giá trị integer 16 bit không dấu. Thứ tự 2 byte ở đây là MSB ,
sau đó đến LSB
Client sẽ phải maintain một danh sách các message IDs để tách biệt với Message
ODs được sử dụng server mà nó kết nối đến. Điều này cho phép việc gửi một
PUBLISH với message ID bằng 1 tại đúng thời điểm nhận một message được
PUBLISH lên server với message ID bằng 1.
Đừng sử dụng Message ID là 0. Nó thường được sử dụng là Invalid Message ID
 UTF-8
UTF-8 (8-bit Unicode Transformation Format - Định dạng chuyển đổi Unicode 8-
bit) là một bộ mã hóa ký tự với chiều rộng biến thiên dành cho Unicode.

UTF-8 có thể biểu diễn tất cả các chữ cái trong bộ ký tự Unicode, nhưng điểm
khác biệt quan trọng nhất là nó có thể tương thích ngược với ASCII. Vì lý do này,
UTF-8 nhanh chóng trở thành bộ mã hóa thống trị trong các tập tin, thư điện
tử, trang web, và các phần mềm xử lý văn bản.

UTF-8 mã hóa mỗi ký tự thành 1 đến 4 octet (tức là byte gồm 8-bit).

128 ký tự đầu tiên của bộ ký tự Unicode (tương ứng một-một với bộ ASCII) chỉ
dùng một octet có cùng giá trị nhị phân như bộ ASCII.
UNUSED BITS

Những bit được đánh dấu không sử dụng thường được set bằng (0)
COMMAND MESSAGES

 CONNECT
 SUBSCRIBE
 CONNACK
 SUBACK
 PUBLISH
 UNSUBSCRIBE
 PUBACK  UNSUBACK
 PUBREC  PINGREQ

 PUBREL  PINGRESP

 PUBCOMP  DISCONNECT

Xem thêm tài liệu để thực hành LAB

5.1. MOSQUITTO MQTT MESSAGING BROKER

MQTT brokers?

Apache ActiveMQ HiveMQ HBMQTT

Apache ActiveMQ Artemis JoramMQ Mosca

Emqttd Mosquitto Moquette

Flespi Emitter MQTTnet

Bevywise MQTTRoute
IBM Integration Bus VerneMQ
5.1.4. MOSQUITTO MQTT MESSAGING BROKER
Which broker to use?
Mosquitto is an open source message broker that
implements the MQTT protocol.

It’s lightweight and suitable for use on all devices from a

low power single board like Arduino, ESP8266 to full
computers and servers.

Cloud-based Mosquitto brokers are many:

 ThingMQ
 ThingStudio
 MQTT.io
 Heroku
 CloudMQTT
5.2. HTTP PROTOCOL

5.2.1. Giới thiệu

5.2.2. Các thành phần cơ bản giao thức HTTP
5.2.3. Định dạng của message/ cấu trúc bức điện
5.2.4. Mosquitto HTTPMessaging Broker
 5.2.1 HTTP PROTOCOL – GIỚI THIỆU
HTTP (HyperText Transfer Protocol
HTTP là một trong các giao thức chuẩn về mạng Internet, được dùng để liên hệ
thông tin giữa Máy cung cấp dịch vụ (Web server) và Máy sử dụng dịch vụ (Web
client), là giao thức Client/Server dùng cho World Wide Web – WWW

HTTP là một giao thức ứng dụng của bộ giao thức TCP/IP
5.2.2 CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC HTTP

HTTP client and server communicate by sending text messages. The client sends
a request message to the server. The server, in turn, returns a response message.
5.2.2 CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC HTTP

An HTTP message consists of a message header and an optional message body,

separated by a blank line, as illustrated below:
 5.2.2 CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC HTTP

HTTP – Requests: The format of an HTTP request message is as follow:

 5.2.2 CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC HTTP

HTTP – Requests line has the following syntax:

request-method-name request-URI HTTP-version

 request-method-name: HTTP protocol defines a set of request methods, e.g.,

GET, POST, HEAD, and OPTIONS. The client can use one of these methods
to send a request to the server.
 request-URI: specifies the resource requested.
 HTTP-version: Two versions are currently in use: HTTP/1.0 and HTTP/1.1.

Examples of request line:

GET /test.html HTTP/1.1
HEAD /query.html HTTP/1.0
POST /index.html HTTP/1.1
 5.2.2 CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC HTTP

HTTP – Requests headers has the following syntax:

request-header-name: request-header-value1, request-header-value2, ...

Examples of request header:

Host: www.xyz.com
Connection: Keep-Alive
Accept: image/gif, image/jpeg, */*
Accept-Language: us-en, fr, cn
a sample HTTP request message
 5.2.2 CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC HTTP

HTTP – Requests methods

GET: A client can use the GET request to get a web resource from the server.
HEAD: A client can use the HEAD request to get the header that a GET request would have
obtained. Since the header contains the last-modified date of the data, this can be used to
check against the local cache copy.
POST: Used to post data up to the web server.
PUT: Ask the server to store the data.
DELETE: Ask the server to delete the data.
TRACE: Ask the server to return a diagnostic trace of the actions it takes.
OPTIONS: Ask the server to return the list of request methods it supports.
CONNECT: Used to tell a proxy to make a connection to another host and simply reply the
content, without attempting to parse or cache it. This is often used to make SSL connection
through the proxy.
 5.2.2 CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC HTTP

HTTP – Response: The format of an HTTP response message is as follow:

 5.2.2 CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC HTTP

HTTP – status line has the following syntax:

HTTP-version status-code reason-phrase

 HTTP-version: The HTTP version used in this session. Either HTTP/1.0 and
HTTP/1.1.
 status-code: a 3-digit number generated by the server to reflect the outcome of
the request.
 reason-phrase: gives a short explanation to the status code.
 Common status code and reason phrase are "200 OK", "404 Not Found", "403
Forbidden", "500 Internal Server Error"
Examples of request line:
HTTP/1.1 200 OK
HTTP/1.0 404 Not Found
HTTP/1.1 403 Forbidden
 5.2.2 CÁC THÀNH PHẦN CƠ BẢN GIAO THỨC HTTP

HTTP – Response headers has the following syntax:

response-header-name: response-header-value1, response-header-value2, ...

Examples of request header:

Content-Type: text/html
Content-Length: 35
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
a sample HTTP response message
 Comparison between MQTT and HTTP protocols
Features MQTT HTTP
Full form Message Queue Telemetry Transport Hyper Text Transfer Protocol
Architecture It has publish/subscribe architecture. Here It has request/response means
devices can publish any topics and can Client/Server architecture.
also subscribe for any topics for any
updates.
Upper layer protocol It runs over TCP. It runs over TCP and UDP.
message size small, . Large,
Message format binary with 2Byte header ASCII format.
Data distribution 1 to 0/1/N one to one only , more POST
Data security Yes, It uses SSL/TLS for security NO, hence HTTPS is used to
provide data security
Complexity Simple Client more complex (ASCII
parser)
Encryption It encrypts payload i.e. it is payload data are not encrypted before
agnostic transmission
6. IOT NETWORKING CONSIDERATIONS AND CHALLENGES

When you consider which networking technologies to adopt within your IoT
application, be mindful of the following constraints:
 Range
 Bandwidth
 Power usage
 Intermittent connectivity
 Interoperability
 Security
RANGE

PAN (Personal Area Network)

PAN is short-range, where distances can be measured in meters, such as a
wearable fitness tracker device that communicates with an app on a cell phone
over BLE.

LAN (Local Area Network)

LAN is short- to medium-range, where distances can be up to hundreds of
meters, such as home automation or sensors that are installed within a factory
production line that communicate over wifi with a gateway device that is
installed within the same building.
RANGE

MAN (Metropolitan Area Network)

MAN is long-range (city wide), where distances are measured up to a few
kilometers, such as smart parking sensors installed throughout a city that are
connected in a mesh network topology.

WAN (Wide Area Network)

WAN is long-range, where distances can be measured in kilometers, such as
agricultural sensors that are installed across a large farm or ranch that are
used to monitor micro-climate environmental conditions across the property.
BANDWIDTH

Bandwidth, or the amount of data that can be transmitted in a specific period of

time, limits the rate at which data can be collected from IoT devices and
transmitted upstream. Consider these factors:
 The volume of data that each device is generating
 The number of devices that are deployed in a network
 Whether the data is being sent as a constant stream or in intermittent
bursts, as the bandwidth that is available will need to cope with the peak
periods
POWER USAGE

Transmitting data from a device consumes power, and transmitting data over
long ranges requires more power than over a short range.
To consider the devices that operate on a battery to conserve power to prolong
the life of the battery and reduce operating costs.
To prolong the battery life, you can put the device into sleep mode whenever it is
idle.
To model the energy consumption of the device under different loads and
different network conditions to ensure that the device’s power supply and storage
capacity matches with the power that is required to transmit the necessary data
by using the networking technologies that you adopted.
INTERMITTENT CONNECTIVITY

IoT devices aren’t always connected. In some cases, devices will connect
periodically by design in order to save power or bandwidth.
However, sometimes an unreliable network might cause devices to drop off due
to connectivity issues.
Sometimes quality of service issues, such as dealing with interference or
channel contention on a wireless network using a shared spectrum.
INTEROPERABILITY

Adopting standard protocols has been the traditional approach for maintaining
interoperability on the internet. However, for the IoT, standardization processes
sometimes struggle to keep up with the rapid pace of change and technologies
are released based on upcoming versions of standards that are still subject to
change. In these cases, consider the ecosystem around the technologies.
SECURITY

Security is always a priority, so be sure to select networking technologies that

implement end-to-end security, including authentication, encryption, and open
port protection
THANK YOU!