IOT Unit3 Web Comm Protocols
IOT Unit3 Web Comm Protocols
Connectivity
Web Communication Protocols for
Connected Devices
• Data of connected Devices routes over the
web in two types of communication
environments. They are,
1. Constrained RESTful Environment (CoRE)
2. Unconstrained Environment
Constrained RESTful Environment
(CoRE)
• IoT devices or M2M devices communicate
between themselves in a Local Area Network.
• A device typically sends 10s of bytes
• After consolidating data from all IoT device ,
size increases to 100s of bytes.
• A gateway communicates data over Internet
using REST software architecture.
• Devices have constraint in sense that their data
is limited in size.
• Another constraint is data routing when Routing
Over a network of Low power and (data) Loss
(ROLL).
• ROLL network is a wireless network with low
power transceiver.
• Next constraint is that the devices may sleep
most of the time in low power environment and
awaken on an event or when required.
• Devices connectivity may break and have limited
up intervals and limited data size.
Unconstrained Environment
• Web application use HTTP and Restful HTTP
for web client and web server
communication.
• A web object consists of 1000s of bytes.
• Data routes over IP networks for Internet.
• Web applications and services use the IP and
TCP protocols for internet network and
transport layers.
10s and 100s of Bytes Communication Framework
Constrained RESTful Environment (CoRE)
IoT or M2M
Web Connectivity
Area Local
Coap://………
Network and Roll
Gateway Web Object Web Object
Device 1 CoAP CoAP DTLS CoAP
10s of bytes UDP Server
Client 100s of
Device 2 LWM2M bytes
10s of bytes
Device 3 10s of bytes
6LowPAN CoAP DTLS CoAP
Server UDP Client
Zigbee NAN 100s of
------------ bytes
10s of bytes
Bluetooth HTTP
Device i-1 Smart IP TLS Server
IP http://……..
TCP HTTP
Device i 10s of bytes
Zigbee IP
1000s of bytes Client
(Unconstrained HTTP http://……..
Environment
01 00 0010 01 10 0010
V CON TKL V ACK TKL
0 1 0 0 0 1 0 1 = 45
• Payload: Followed by the optional token and
zero or more option fields, the payload may
start, in which case a payload marker 0xFF is
placed in between. This indicates the end of
the options and the start of the payload. The
absence of the payload marker indicates an
empty payload.
•
• Payload: Followed by the optional token and
zero or more option fields, the payload may
start, in which case a payload marker 0xFF is
placed in between. This indicates the end of
the options and the start of the payload. The
absence of the payload marker indicates an
empty payload.
•
(A) Direct and Indirect Access of CoAP Client objects to a CoAP Server
(B) CoAP Client Access for lookup of object or resource using a Resource Directory
IoT Area Direct Access CoAP IoT App
Local Network Server
CoAP /ms
Client CoAP Mirror Update
Object 1 Client Server
Indirect Access (A)
-
- Lookup for object/Resources CoAP
IOT IoT App
- Access Client
Devices
/rd
CoAP Resources CoAP IoT App
Object i
Client Directory Server
(B)
HTTP
CoAP-HTTP
CoAP Client Server
CoAP Proxy
Server HTTP-CoAP CoAP
Proxy Client
(C)
(C) CoAP Client and Server Access using Proxies IoT App
• In machine-to-machine (M2M) applications
where there are no humans in the loop, it is
important to provide a way to discover
resources offered by a constrained server.
• Discovery of resources hosted by web servers
(CoAP or HTTP) is specified by the well-known
relative URI “/.well-known/core”.
• It is defined as a default entry-point for
requesting a list of links to resources hosted by a
server.
• Once the list of available resources is obtained
from the server, the client can send further
requests to obtain the value of a certain
resource.
CoRE direct resource discovery & CoAP
Request
• In many M2M scenarios, nodes might have long
sleeping periods and thus making direct
discovery of resources not practical.