SmartCoAP: Internet of Things

monitoring tool
Presented by :
Tushalkumar Jogani

Thesis supervisor :
dr inż. Jarosław Domaszewicz

Institute of Telecommunications
Warsaw University of Technology
• Introduction
• Literature review
• SmartCoAP
– Message parsing
– Error detection
– Average messages length calculations
• CoAP pseudo-server
– Resource discovery
– Error generations
• Testbed – Error detection
• CoAP message length investigations
• Summary and Future work
 Introduction

• CoAP – Constrained Application Protocol (RFC7252)

• Web transfer protocol for use with constrained nodes and constrained networks
• Designed for M2M (Machine to Machine)
• Designed to enable low-power sensors to use RESTful service
• Based on Request-Response model
• Asynchronous over a UDP (Built over UDP)
• Low header overhead and parsing complexity
• Simple proxy capabilities (CoAP-to-HTTP, HTTP-to-CoAP)
 CoAP message format
• Four-byte header
– Version (01) -2-bit
– Type (Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3)) -2-bit
– Token length (0-8 bytes) -4-bit
– Code (Request - 0.xx (GET, POST, PUT, and DELETE), Response - 2.xx, 4.xx, 5.xx) - 8-bit
– Message id - 16-bit
• Token
• Options (Uri-Path, Content-Fomat, Etag, Block2, Max-Age and others)
– The Uri-Path option contains the path to the desired resource on the remote device.
– Block2 (NUM/M/SZX) - the number of the sent block (NUM), the block size (Size), and
whether there are more blocks to follow (M). (CoAP blockwise transfer)
– Resource discovery (rfc6690) - .well-known/core
– Observe - client sends observe option in the request
• Payload - payload marker (0xFF)

Figure : Message Format (RFC7252)

 CoAP Client-Server model

Figure : Client-Server model

Application • CoAP, MQTT, AMQP, XMPP

layer
• DTLS
Transport layer • TCP/UDP

• IPv4/IPv6
Network layer • 6LoWPAN, RPL

• IEEE 802.15.4, IEEE 802.15.6,

PHY/MAC layer WirelessHART, UWB, Bluetooth Low
Energy (BLE), LoRAWAN, Z-Wave, NB-IoT
Figure : Protocol stack
 Literature review

• Wireshark - offers inspections for a lot of protocols, GUI, can analyze CoAP message

• Tcpdump - offers inspections for TCP/IP stack, cannot analyze CoAP message

• EtherApe - graphical network-monitoring tool, cannot analyze CoAP message

 SmartCoAP Architecture

Figure : Architecture of the SmartCoAP tool

(Kurose, J. F., and K. W. Ross. "Ethereal Lab: Getting Started." USA: All Rights Reserved (2005).)
SmartCoAP - Objectives

Figure : SmartCoAP monitoring tool objectives

 Prototype setup

Figure : Client and server communication and monitoring tool

Packet sniffer

Figure : Packet sniffer algorithm

CoAP message parsing

Figure : CoAP message parsing algorithm

 Example Request-Response

• The client sends a confirmable GET

request message on the resource
coap://coap.me/hello; a message id
(0x043d) and token (0xabab) are both sent
in the request message.
• The request includes one Uri-Path option
(option Delta = 11, Length 5, Value
"hello") and one Block2 option. The size
of the request message is 14 bytes

Figure : CoAP Response captured by SmartCoAP

 Example Request-Response

• The server sends back a 2.05 Content

response in an acknowledgment (ACK)
message, including a message id, token,
and payload.

• The response echoes both the message id

and the token contained in the request, and
it includes the payload "world”. The size
of the response message is 18 bytes.

Figure : CoAP Response captured by SmartCoAP

 Error detection logic
1. Wrong version number error - If version field contains a value other than binary “01”

2. Token length error - If the value of the token length is greater than 8

3. Undefined request/response code error - If the code is other than a valid request or response
(0.xx, 2.xx, 4.xx and 5.xx)

4. Unknown option error - If the current option number (the sum of the current option delta
value and the number of the previous option) is other than one of any of defined options

5. Zero-length payload error - If a payload marker (0xFF) is followed by a zero-length payload

6. Message id mismatching error - the message id of a response does not match one of
message ids stored in the request message id list

7. Token mismatching error - the token of a response does not match one of token stored in
the request token list
 Average messages length calculation

• can be calculated as:

• CoAP_message_length = size_of (fixed_size_header) + size_of (variable_length_token) +
size_of (options) + size_of (payload) (1)
• where size_of (fixed_size_header) = 4 bytes, and size_of (variable_length_token) = 0 to 8
bytes.
• The average message length is given by

(2)

• where N is the total number of messages of a given category (see below).

• type - “GET Request”, “GET Response”, “GET Total”, “PUT Request”, “PUT Response”,
“PUT Total”, “POST Request”, “POST Response”, “POST Total”, “DELETE Request”,
“DELETE Response”, “DELETE Total”, “ALL Request”, “ALL Response”, and “ALL Total”
 Average messages length calculation

• Figure shows the processing of a GET

request message and it contains statistics
for the corresponding categories “GET
Request”, “GET Total”, “ALL Request”,
and “ALL Total”.
• The statistics include the number of
messages of a given category encountered
so far, the sum of the lengths of these
messages, and the average message length.
• For example, the tool detected five
messages (three GET + two PUT
requests) of the “ALL Request” category,
whose lengths added up to 75 bytes. As a
result, the average message length of a
request (any request) is 15 bytes.

Figure : Processing of a request message

 Average messages length calculation

• Figure shows the processing of a response

to a GET request message.

Figure : Processing of a response message

CoAP pseudo-server

Figure : Flowchart of the CoAP pseudo-server

Resources discovery - Copper client

Figure : Pseudo-server resources retrieved on the Copper client

Testbed - Error detection

Figure : Testbed - Error detection

Average messages length investigation
• Publicly available servers
– coap://coap.me
– coap://californium.eclipse.org
• Investigation factors – Resource path size, Options size and Payload size

Figure : GET Request message length investigation (coap://coap.me )

Average messages length investigation

Figure : GET Response message length investigation (coap://coap.me )

Average messages length investigation

Figure : GET Response message length investigation (coap://coap.me ) - without payload

Average messages length investigation
• Table describes the summary of the average length calculation of the CoAP GET method
using two publicly available servers.
• Based on the experiment, it is clear that the length of a request is primarily dependent on the
size of the resource path.
• On the other hand, the length of a response is primarily dependent on the size of the payload.

Table : CoAP message length investigation

Publicly available test Average length

servers [Bytes]
GET GET GET GET GET
Request Response Response Total Total
(Without (Without
payload) payload)
coap.me 16.7 78 16.37 47.03 16.65

californium.eclipse.org 19.76 94 10.86 56.62 15.32

 Summary and Future work
• Summary
• Successfully parsed CoAP message
• Successfully tested SmartCoAP using the pseudo-server (Error detections)
• Successfully assess the average length of CoAP messages ( GET requests and GET responses)

• Future work
– Smartcoap
– Focus on extending the variety of detected errors - like timeouts and retransmissions
– Add message categorization for the purpose of average message length calculations
(e.g., taking into account source and destination IP addresses).
– Pseudo-server
– Support for responses to the PUT, POST, and DELETE requests

• More user-friendly user interface

Thank you
Appendix
Testbed – CoAP Request-Response

Figure : CoAP Request-Response testbed

Resource discovery

Figure : Resource discovery

Winpcap

Figure : Winpcap library

Confirmable request and Separate
response

Figure : Error response results of GET method [1]: (a) … and (b) … ((RFC7252))
Confirmable request and Piggybacked
response

Figure : Error response results of GET method [1]: (a) … and (b) … ((RFC7252))
Non-confirmable request and
response

Figure : Non-confirmable request and response error (RFC7252)

Prototype setup
 Message layer and request/response
layer
• The communication on top of UDP bases on two layers - message layer and request/response layer
• First, there is the message layer. Inside the message layer, messages can be declared as confirmable (CON), non-confirmable
(NON), acknowledgement (ACK), or reset message (RST). A reliable communication is achieved by CON messages similar
to a TCP transmission. After having sent a CON message, an ACK message is expected to confirm the successful
transmission The assigning of the ACK message to a CON message is done by a message ID. If the sender of a CON message
does not get the acknowledgement within a timeout, it sends the message again.
• The request/response layer is above the message layer to enable the request/response principle between the network
participants. In this layer, the basic methods are performed, e.g., a GET or PUT method.
• The default CoAP port is 5683.