Design Principles for Web

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

Physical/Data Link Application Network Transport Application Support

Layer and Application Layers
Layer Layer Layer

IoT or M2M devices local network connectivity and web connectivity in

constrained and unconstrained RESTful HTTP environments using
communication protocols
 Constrained Application Protocol
• IETF (Internet Engg Task Force) recommends
CoAP for CoRE using ROLL data network.
Features of CoAP are:
1. An IETF defined application-support layer
protocol.
2. CoAP defined in RFC(Request for Comments)
7252.
3. CoAP web objects communicate using
request/response interaction model.
Request/Response sub-layer is responsible for communication
Message sub-layer is responsible for reliability and duplication of
messages
 CoAP
• The CoAP interaction model is similar to the client/server
model of HTTP.
• A client can send a CoAP request, requesting an action
specified by a method code (GET, PUT, POST or DELETE) on a
resource (identified by a URI) on a server.
• The CoAP server processes the request and sends back a
response containing a response code and payload.
• Unlike HTTP, CoAP deals with these interchanges
asynchronously over a datagram-oriented transport layer
such as UDP and thus also supports multicast requests.
• This allows CoAP to be used for point-to-multipoint
interactions which are commonly required in automation.
• Secure communication is also supported through the
optional use of Datagram Transport Layer Security (DTLS)
 CoAP Frame format
Version; fixed 0x01
Type of message
Token Length
Request/Response Code
Match Con to Ack

Match Req to Resp

CoAP has 4 byte Header with optional fields

Type Message Type Explanation
00 Conformable Must be acknowledged,
message (CON) if ack not received then
retransmit message
01 Non- Need not to be
Confirmable acknowledged
message (NON)
10 ACK Acknowledgement
11 RST Reset, if recipient is unable to
process message, it sends RST
2.05 is response code like HTTP 200 “OK” ; in response to GET request

Message IDs are unique values that are used

to identify duplicate messages, and match
confirmable messages (CON) to
acknowledgements (ACK).

Tokens are unique values used to match

requests to responses.
• CoAP URIs: CoAP URIs consist of
– the hostname, port number, path and query string,
which are specified by option fields
– Uri-Host, Uri-Port, Uri-Path and Uri-Query, of which Uri-
Host and Uri-Port are implicit as they are part of
underlying layers.
– Uri-Path and Uri-Query are significant and part of the
CoAP message.
coap-URI = "coap:" "//" host [ ":" port ] path [ "?" query ]
• For example, if we request a resource with
URI coap://hostname:port/leds/red?q=state&on, the
following options are generated:
Option#1 Uri-Path Leds,
Option#2 Uri-Path red,
Option#3 Uri-Query q=state
Option#4 Uri-Query on.
• CODE(8 bits) Request/Response Code
• Indicates if the message carries a request (1-31) or a response
(64-191), or is empty (0). (All other code values are reserved.)
In case of a request, the Code field indicates the Request
Method; in case of a response a Response Code.
• CoAP request consists of methods as GET, POST, PUT,
DELETE.
– A 3-bit class ID and 5-bit detail in the c.dd format forms
this field. The classes are:
0 Requests
2 success responses
4 client error responses
5 server error responses
The detail carries the request code or response code.
• Message ID: A 16-bit unsigned number in
network byte order is used to match
acknowledgement or reset messages and
eliminate duplicate messages.
• Tokens: An optional token field, which is limited
to 0 to 8 bytes currently to match request
responses, may be kept after the header, which is
of TKL number of bytes specified in the header.
Options: Zero or more option fields may follow a
token. A few options are Content Format, Accept,
Uri-Path, Uri-Query, etc.
 CoAP Request Response

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.

• To solve this problem, the CoAP community has

proposed to use CoRE Resource Directories (RD)
that host descriptions of resources held on other
servers.
• This way a CoAP server can register its
resources with one or more RDs.
• Clients in turn can discover these resources by
performing lookups against an RD.
• A second relevant CoAP mechanism is that of
a CoRE Mirror Server. Such a ,mirrors the
resources of a constrained devices, thereby
enabling these devices to go into sleep mode
and to disconnect their network link in order
to save resources.
IoT Protocol Stack
• DTLS security is based on PSK, RPK and
certificate.
 Secured Use of a Key for Client
Authentication
Pre-Shared Key (PSK)
• Key contains 133 characters in English
• Generates unique encryption key for each
client
• Symmetric key (not secret from receiver)
• Both ends, Encryption and Decryption, use
same key.
• Random Pair-wise Keys (RPK)/ Raw Public Key
• Sender used key pair (K1 and Kp)
• Receiver used key pair (K2 and Kp)
• Public Key (Kp) refers to 128/256 bits key which a
trusted intermediate such as Bank server
provides to sender and receiver.
• K1 is used by sender and K2 by receiver
respectively while communicating with server
and server uses Kp.
• Keys K1 and K2 are kept secret.
 X.509 Certificate
• X.509 certificate is a certificate with a chain of
trust based on an authorized Certification
Authority (CA) and Public Key Infrastructure
(PKI).
• Sender submits document to CA for digital
signature.
• CA issues a certificate of verification.
• Later, the document can be authenticated by
CA.