Lecture Notes Application Protocols

• serial interface to a gateway tunneling

• translating traffic

Devices that are very constrained in resources

Devices with enough power and capacities to implement a stripped-down IP stack or non-IP stack

Devices that are similar to generic PCs in terms of computing and power resources but have constrained networking capacities, such as bandwidth

They may communicate infrequently to transmit a few bytes, and may have limited security and management capabilities. This drives the need for the IP adaptation model, where nodes communicate through gateways and proxies.

In this case, we may implement either an optimized IP stack and directly communicate with application servers (adoption model) or go for an IP or non-IP stack and communicate through gateways and proxies (adaptation model).

These nodes usually

implement a full IP stack (adoption model), but network design and application behaviors

must cope with the bandwidth constraints.

limited by low-power, low-bandwidth links (wireless and wired)

packet delivery rate (PDR) to oscillate between low and high percentages.

Unstable link layer environments create other challenges in terms of latency and control plane reactivity. One of the golden rules in a constrained network is to underreact to failure.

Control plane traffic must also be kept at a minimum;

• Application protocol: Modbus TCP onyl IPv4

• Cellular Provider and Technology: GPRS, Edge, and 3G - IPv4

• Serial Communications: connect the serial port of the legacy device to a nearby serial port on a piece of communications equipment, typically a router. This local router then forwards the serial traffic over IP to the central server for processing. Encapsulation of serial protocols over IP leverages mechanisms such as raw socket TCP or UDP. While raw socket sessions can run over both IPv4 and IPv6, current implementations are mostly available for IPv4 only

• IPv6 Adaptation Layer: support only IPv6

adaptation of this layer's functions to Link layer technologies with restricted frame size

in the worst case, 81 bytes per frame to cram the IPv6 packet into

IPv6 over low-power wireless personal area networks (6LoWPAN)

three main functions:

• IPv6 header compression,

• IPv6 packet segmentation and reassembly, and

• layer 2 forwarding (also referred to as mesh under)

headerstacks supported, when needed a header can be added

With 6LowPAN, it is possible to compress the IPv6 header into 2 bytes

The combined IPv6's 40-byte headers and User Datagram Protocol's (UDP's) 8 byte headers can be shrinked down as low as 6 bytes in some cases

is only defined for an IPv6 header and not for IPv4.

MTU for an IPv6 network must be at least 1280 bytes

IEEE 802.15.4, 127 bytes is the MTU.

forward packets over multiple hops

Three fields are defined for this header: Hop Limit, Source Address, and Destination Address

network technologies that support mesh topologies and opperate at the physical and data link layers two options for establishing reachability

1. mesh-under: routing is handelded at the 6LoWPAN adaption layer

2. mesh-over/route-over: utilizes IP routing uses mesh addressing header at link layer, multiple link layer hops can make a single IP hop, full functionig nodes act as an IP router

• constrained nodes

• lossy links

• low data rate

• unstable

• low packet delivery rate

• traffic patterns are not point-to-point

• many thousand notes

each node is router an becomes part of a mesh network

routing at the IP layer

each node examines every packet, no need to examine MAC-layer header (mesh-over)

two modes

1. storing mode: all nodes have full routing table of RPL domain

2. non-storing mode: only border router know the full routing table, every other router only knows their list of partens and uses default routes torwards the border router

DAG

directed graph without cycles

from any point you can not follow an edge to get back the the point of origin

all paths are oriented toward and terminating at one or more root nodes.

building a destination oriented DODAG

occurs at a border router (DODAG root)

each nodes has up too three parents that provide path to root (one parent is preffered parent)

disallowing nodes from selecting a parent that is further away from root than self (makes network loop free)

upwards routes are discovered and configured using DAG Information Object (DIO) messages

information in DIO message determine parents and therefor best path to root

nodes establish downward route using a Destination Advertisment Object (DAO) message, inform parents of present and reachability

in case of non storing mode DAO are sent directly to the root

in case fo storing mode DAO are stored by every node (more resources are needed for storing the routing tables, but routes may be shorter)

defines how nodes select and optimeze routes within a RPL instance.

identifyed by an objective code point within the DIO configuration

defines how nodes translate one or more metrics and constraintes into a rank (approximates nodes distance from root)

defines how to select parents

routing constraints or metrics can be used to define node/link characterisitics

• throughput: support wide range of throughputs, can be due to coding or trading power consumption for bit rate

• latency: wide range due to trading power consumption

• link reliabilty: can degrade due to

  • signal attenuation

  • interferences

• link color object: administrative to avoid or attrac specific link for specific traffic types

approximation how close the node is to root

helps avoid routing loops and count to infinity problem

increase their rank when receiving a DIO with larger version number

decrease anytime they discover a route with lower costs

depends on OF

on-demand loop detectin using data packets

traffic can be infrequent and maintaing routing topology can be waste of energy

An inconsistency between the routing decision for a packet (Upward or Downward) and the Rank relationship between the two nodes indicates a possible loop. On receiving such a packet, a node institutes a local repair operation.

reposible for handling communication between application entities

support flow of data

define semantics and mechanisms for message exchanges bewtween endpoints

many different competing porotocols, with no path towards convergence

desision should be based on

• use case

• vertical industries

• lower layers

• 
  

in the TCP/IP protocol stack

• TCP: connection oritented with session

• UDP: connection less with no guarantee of delivery

TCP is main protocol in communication with humans: relaible, reasable data in correct order, flow control, etc (high overhead)

UDP when network services: DNS, NTP, SNMP, DHCP and real time communication

categories of IoT application protocols

• Application layer protocol not present: In this case, the data payload is directly trans- ported on top of the lower layers. No application layer protocol is used.

• Supervisory control and data acquisition (SCADA): SCADA systems contol and monitor industrial processes local or remotely. There are various industrial protocols for SCADA systems developed long before the days of IP, and they have been adapted for IP networks.

• Generic web-based protocols: Ethernet, Wi-Fi, or 4G/LTE, are found on many consumer- and enterprise-class IoT devices that communicate over non-constrained networks. Web-based protocols are well suited for such devices and networks.

• IoT application layer protocols: IoT application layer protocols are designed to run on constrained nodes and are well adapted to the network bandwidth constraints on cellular or satellite links or constrained 6LoWPAN networks. Message Queuing Telemetry Transport (MQTT) and Constrained Application Protocol (CoAP) are two well-known examples of IoT application layer protocols.

data allready in payload of MAC layer

not standardized —> difficult to have generic implementation

may need data broker

piece of middleware that standardize sensor output into a common format

Supervisory Control and Data Acquisition

control system architecture comprising computers, networked data communications and graphical user interfaces (GUI) for high-level process supervisory management

At a high level, SCADA systems collect sensor data and telemetry from remote devices, while also providing the ability to control them

serial communications protocol originally published by Modicon (now Schneider Electric) in 1979 for use with its programmable logic controllers (PLCs)

de facto standard communication protocol

openly published and royalty-free

based on a master/worker relationship

Only one master (at the same time) is connected to the bus, and one or several workers nodes are also connected to the same serial bus. A maximum of 247 workers can be connected to this master. A Modbus communication is always initiated by the master

The worker nodes will never transmit data without receiving a request from the master node. The worker nodes will never communicate with each other. The master node initiates only one Modbus transaction at the same time.

describes how the Modbus protocol must be adapted to run over TCP

Modbus TCP Management layer implements the use of the Modbus Application Protocol over TCP/IP. It manages the connection establishment and ending, and manages the data fow on established TCP connections. The listening TCP port 502 is reserved for Modbus communications. In this layer integrated is the Access Control Module. The goal of this module is to check every new connection and using a list of authorized remote IP addresses the module can authorize or forbid a remote Client TCP connection. Use of the Access Control Module is optional.

Modbus TCP/IP is not limited to 247 devices, as it was the case with Modbus Serial. The addressing is done via the IP addresses of the Modbus TCP/IP devices.

The Modbus worker address feld usually used on Modbus Serial Line is replaced by a single byte Unit Identifer within the MBAP Header. The Unit Identifer is used to communicate via devices such as bridges, routers and gateways that use a single IP address to support multiple independent Modbus end units.

All Modbus requests and responses are designed in such a way that the recipient can verify that a message is finished. For function codes where the Modbus PDU has a fxed length the function code alone is suffcient. For function codes carrying a variable amount of data in the request or response, the data feld includes a byte count.

When Modbus is carried over TCP, additional length information is carried in the MBAP header to allow the recipient to recognize message boundaries even if the message has been split into multiple packets for transmission.

Transaction Identifer: It is used for transaction pairing, the MODBUS server copies in the response the transaction identifer of the request.

ˆProtocol Identifer: It is used for intra-system multiplexing. The MODBUS protocol is identifed by the value 0.

ˆLength: The length feld is a byte count of the following felds, including the Unit Identifer and data fields.

ˆUnit Identifer: This feld is used for intra-system routing purpose. It is typically used to communicate to a Modbus serial line worker through a gateway between an Ethernet IP network and a Modbus serial line. The destination IP address identifes the bridge itself and the bridge uses the Modbus Unit identifer to forward the request to the right worker device. On Modbus TCP/IP, the Modbus server is addressed using its IP address; therefore, the Modbus Unit Identifer is useless. The value 0xFF has to be used.

easily developed because web developer can use their knowledge

web server software with advanced features are now implemented with very little memory

When considering web services implementation on an IoT device, the choice between supporting the client or server side of the connection must be carefully weighed

advanced development in data modeling should be considered as a way to shift the workload from devices to clients

Extensible Messaging and Presence Protocol

originally designed for instant messaging, contact list, and presence information

message-centric protocol based on the Extensible Markup Language (XML)

positioned for smart grid solutions

XMPP Standards Foundation (XSF) actively develops open extensions to the protocol.

native transport protocol for XMPP is TCP

new lightweight protocols that are better suited to large numbers of constrained nodes and networks

almost always find CoAP deployed over UDP and MQTT running over TCP

Constrained Application Protocol

standardized by the IETF Constrained RESTful Environments (CORE)

targeted for constrained nodes in low-power and lossy networks

uses short headers to reduce message sizes

designed to facilitate the exchange of messages over UDP

CoAP implementation acting in both client and server roles

CoAP request is equivalent to that of HTTP and is sent by a client to request an action (using a Method Code) on a resource (identifed by a URI) on a server—> server then sends a response with a Response Code

uses a short fixed-length binary header (4 bytes) that may be followed by compact binary options and a payload, message format is shared by requests and responses

CoAP defines four types of messages:

• Confirmable,

• Non-confirmable,

• Acknowledgement, and

• Reset.

Method Codes and Response Codes included in some of these messages make them carry requests or responses. The basic exchanges of the four types of messages are somewhat orthogonal to the request/response interactions; requests can be carried in Confirmable and Non-confirmable messages, and responses can be carried in these as well as piggybacked in Acknowledgement messages.

based on the REST architecture, but with a thing acting as both the client and the server.

requests and responses are exchanged asynchronously

Methods:

• GET,

• POST,

• PUT, and

• DELETE.

Version (V): 2-bit unsigned integer. Indicates the CoAP version number. Implementations of this specification MUST set this field to 1 (01 binary). Other values are reserved for future versions.

ˆType (T): 2-bit unsigned integer. Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

ˆToken Length (TKL): 4-bit unsigned integer. Indicates the length of the variable-length Token field (0-8 bytes).

ˆCode: 8-bit unsigned integer, split into a 3-bit class (most significant bits) and a 5-bit detail (least significant bits). The class can indicate a request (0), a success response (2), a client error response (4), or a server error response (5). (All other class values are reserved.) As a special case, Code 0.00 indicates an Empty message. In case of a request, the Code field indicates the Request Method; in case of a response, a Response Code.

Message ID: 16-bit unsigned integer. Used to detect message duplication and to match messages of type Acknowledgment/Reset to messages of type Confirmable/Non-confirmable.

the Token value, which may be 0 to 8 bytes, as given by the Token Length field. The Token value is used to correlate requests and responses

zero or more Options. An Option can be followed by the end of the message, by another Option, or by the Payload Marker and the payload.

optional payload. If present and of non-zero length, it is prefixed by a fixed, one-byte Payload Marker (0xFF), which indicates the end of options and the start of the payload. The payload data extends from after the marker to the end of the UDP datagram, i.e., the Payload Length is calculated from the datagram size.

it is recommended that the message fit within a single IP packet and UDP payload to avoid fragmentation

coap-URI = “coap:” “//” host [ “:” port ] path-abempty [ “?” query ]

If the host component is provided as an IP-literal or IPv4address, then the CoAP server can be reached at that IP address. If host is a registered name, then that name is considered an indirect identifier and the endpoint might use a name resolution service, such as DNS, to find the address of that host. The port subcomponent indicates the UDP port at which the CoAP server is located. If it is empty or not given, then the default port 5683 is assumed.

While running over UDP, CoAP o ers a reliable transmission of messages when a CoAP header is marked as confirmable. In addition, CoAP supports basic congestion control with a default time-out, simple stop and wait retransmission with exponential back-off mechanism, and detection of duplicate messages through a message ID. If a request or response is tagged as confirmable, the recipient must explicitly either acknowledge or reject the message, using the same message ID. If a recipient can't process a non-confirmable message, a reset message is sent.

After receiving and interpreting a request, a server responds with a CoAP response that is matched to the request by means of a client-generated token.

There are 3 classes of Response Codes:

ˆ 2 - Success: The request was successfully received, understood, and accepted.

ˆ 4 - Client Error: The request contains bad syntax or cannot be ful lled.

ˆ 5 - Server Error: The server failed to ful ll an apparently valid request.

Message Queuing Telemetry Transport (MQTT) protocoll

lightweight publish/subscribe messaging protocol

designed by IBM

roles:

• MQTT client: has an unique ID

  • publisher/resource information

  • subscriber

• MQTT server/MQTT message broker

uses TCP

can use TLS on port 8883

2 byte fixed header

control packet can have payload of up to 256 MB

PINGREQ/PINGRESP control packets are used to validate the connections between the client and server

can subscribe to all data or to specific data form tree of a publisher

• establishment

• authentication

• data exchange

• session termination

  
  

Subscriptions to resources generate SUBSCRIBE/SUBACK control packets, while unsubscription is performed through the exchange of UNSUBSCRIBE/UNSUBACK control packets.

Graceful termination of a connection is done through a DISCONNECT control packet, which alsooffers the capability for a client to reconnect by re-sending its client ID to resume the operations.

The forward slash (/) in an MQTT topic name is used to separate each level within the topic tree and provide a hierarchical structure to the topic names.

Wide fexibility is available to clients subscribing to a topic name. An exact topic can be subscribed to, or multiple topics can be subscribed to at once, through the use of wildcard characters. A subscription can contain one of the wildcard characters to allow subscription to multiple topics at once.

The pound sign (#) is a wildcard character that matches any number of levels within a topic. The multilevel wildcard represents the parent and any number of child levels.

The plus sign (+) is a wildcard character that matches only one topic level.

Topic names beginning with the dollar sign ($) must be excluded by the server when subscriptions start with wildcard characters (# or +).

three levels of quality of service

QoS 0: This is a best-e ort and unacknowledged data service referred to as at most once delivery. The publisher sends its message one time to a server, which transmits it once to the subscribers. No response is sent by the receiver, and no retry is performed by the sender. The message arrives at the receiver either once or not at all.

ˆQoS 1: This QoS level ensures that the message delivery between the publisher and server and then between the server and subscribers occurs at least once. In PUBLISH and PUB-ACK packets, a packet identifier is included in the variable header. If the message is not acknowledged by a PUBACK packet, it is sent again. This level guarantees at least once

delivery.

ˆQoS 2: This is the highest QoS level, used when neither loss nor duplication of messages is acceptable. There is an increased overhead associated with this QoS level because each packet contains an optional variable header with a packet identifier. Confirming the receipt of a PUBLISH message requires a two-step acknowledgement process. The first step is done through the PUBLISH/PUBREC packet pair, and the second is achieved with the PUBREL/PUBCOMP packet pair. This level provides a guaranteed service known as exactly once delivery, with no consideration for the number of retries as long as the message is delivered once.