Protocols for Fog Computing: RTPS/DDS

FOG COMPUTING?
In a line: Just an intermediate layer between the Cloud and the devices of the IoT.

Fog computing is a new term from Cisco for an alternative to the cloud computing model. It adds
another layer of intelligence at the edge of a network to process some analytics and take some
decisions there, instead to process everything in the cloud.

This new layer of intelligence is added to some access points such as routers: yes, a lot of
mystery to sell you new devices. But the fact is, cloud computing is not good for all scenarios,
and sometimes it is better to process the data right away near where it is produced, minimizing
latency and saving bandwidth. That sounds like a slogan for DDS/RTPS right?

A FOG COMPUTING EXAMPLE: SMART GRIDS

Imagine a complex smart grid with power-line communications, smart meters, a lot of phasor
measurement units, different power sources, a mix of electrical substations and everything
distributed geographically using a hierarchical schema.

It is straight-forward, you cannot use the cloud computing model in this case, you need to add
some intelligence to the intermediate nodes in order to make fast decisions, and also to save
bandwidth, because the amount of generated data from the different nodes and meters is huge.
More Examples
Virtually any big hierarchical distributed system (smart cities applications) can be modeled that
way, and I would say this is really the default design, nothing new.

DDS/RTPS AS FOG COMPUTING PROTOCOLS

The main Fog computing goal is minimize latency and save bandwidth, adding some
intelligence to the access point to optimize the typical scenarios in the IoT. Examples of fog
computing scenarios include low power devices, real-time requirements, and wireless networks.

Taking into account these requirements, a good Fog computing protocol should be lightweight,
transport agnostic and customizable. Heavyweight Protocols such as Web Services or REST are
discouraged because consume a lot of resources in terms of bandwidth and CPU use. Remember
the IoT devices include small sensors, embedded devices and low bandwidth data links.

The Data Distribution Service (DDS) middleware standard is widely known for being used in
very exigent real-time distributed systems in Aerospace and defense systems, and its underlying
protocol RTPS (Real Time Publish Subscribe Protocol) main features make it very suitable for
the goals of fog computing:

 Designed for real-time distributed systems: low latency communications and low

bandwidth use.

 Highly customizable: It allows to setup different Quality of Service parameters for

different kinds of data or different data links.

 Wireless enabled: It can be deployed over any transport/data link, including specifically

disconnected and intermittent data links, such as low bandwidth wireless networks. RTPS

supports multicast, a very recommendable feature in this kind of networks, and it can also

be deployed over non IP-Based data links.

 Lightweight: It requires very few resources, and it can be implemented in low power

devices.
RTPS Introduction
WHAT IS RTPS?
RTPS (Real Time Publish Subscribe Protocol) is a protocol for best effort and reliable pub-sub
communications over unreliable transports such as UDP in both unicast and multicast.

RTPS has been standardized by the OMG (Object Management Group) as the interoperability
protocol for Data Distribution Service (DDS) implementations, an standard widely used in the
aerospace and defense sectors for real-time applications.

Besides the RTPS implementations embedded in the different DDS implementations, there are
standalone lightweight RTPS implementations.

RTPS ADVANTAGES:
The main features of the RTPS protocol are:

 Performance and Quality-of-Service (QoS) properties enabling best-effort and reliable

publish-subscribe communications for real-time applications using standard IP

networks.

 Fault tolerance allowing the creation of networks without single points of failure.

 Extensibility allowing backward compatibility and interoperability through extensions of

the protocol and enhancement with new services.

 Plug-and-play connectivity for new applications and services allowing automatic,

configuration-less discovery by applications joining and leaving the network at any time.

 Configurability allowing balancing the requirements of reliability and timeliness for

each data delivery transaction.

 Modularity allowing simple devices to implement a subset of the protocol and still

participate in the publish-subscribe network.

 Scalability enabling systems to scale to very large publish-subscribe networks.

  Type-safety preventing application programming errors compromising the operation of

remote nodes in the publish-subscribe network.

RTPS ARCHITECTURE:
The RTPS wire protocol is based on four different modules that control the exchange of
information between the different DDS applications.

 The Structure module defines the communication endpoints and maps them to their

DDS counterparts.

 The Message module defines which messages can these endpoints exchange and how

they are built.

 The Behavior module defines a set of legal interactions and how they affect each of the

endpoints.

 The Discovery module defines a set of built-in endpoints that allow the automatic

discovery.

A brief explanation of each of the modules and their parts is included below:

STRUCTURE MODULE:
Since RTPS is the wire protocol designed to implement DDS applications, each DDS concept or
entity naturally maps to an RTPS entity. All RTPS entities are associated with an RTPS domain,
which represents a separate communication plane that contains a set of Participants. Each RTPS
Participant can contain multiple local Endpoints of two different kinds: Writers and Readers.
These two endpoints exchange information in the RTPS network by sending RTPS messages.
The Writers send the locally available information to the Readers, which, in turn can request or
acknowledge the data.
The interface between the RTPS endpoints (Writer and Readers) and its corresponding DDS
entities is the HistoryCache. The information exchanged between the endpoints its usually stored
in a CacheChange. For example, each write operation introduces a CacheChange in the Writer
History. The RTPS Writer then sends an RTPS message to all matching Readers. Upon receipt,
the RTPS Reader adds the CacheChange to its corresponding HistoryCache and notifies the DDS
entity that a new data is available.

MESSAGE MODULE:
The messages module defines the content of the atomic information exchanges between RTPS
Writers and Readers. RTPS Messages are composed of a header followed by a number of
Submessages. The Header identifies the message as part of the RTPS protocol, as well as the
version of the protocol being used and the vendor that sent the message. It also identifies the
Participant that is sending the message.

Each Submessage is composed of a Submessage Header and a series of Submessage elements.

This structure is chosen to allow the vocabulary of Submessages and the composition of each
Submessage to be extended while maintaining backward compatibility. The Submessage Header
contains the submessage Id that identifies the type of submessage, the submessage length in
bytes and the submessage flags. There are twelve different kind of submessages. For a complete
description of all messages, its composition and interpretation please consult the OMG RTPS
specification document. The three most important messages are:

 DATA: This submessage is sent from a Writer to a Reader with information regarding a

change to a data-object belonging to a Writer. This change can be in value (new

information being added) or in the life-cycle (a previously sent data is no longer valid).

 HEARTBEAT: This submessage is sent from a Writer to a Reader communicating the

CacheChanges that the Writer has available at this moment.

  ACKNACK: This submessage is sent from a Reader to a Writer, and allows the Reader to notify

the Writer about which changes it has received and which ones are still missing. It can be used to

do both positive and negative acknowledgements.

BEHAVIOR MODULE:
This module describes the valid messages exchanges that can occur between a Writer and a
Reader. It also defines the changes in the state of the Writer and Reader depending on each
message. A full set of rules can be found in the OMG RTPS specification document. These rules
are set in order to ensure interoperability between different implementations.

DISCOVERY MODULE:
This module describes the protocol that enables Participants to obtain information about the
existence and attributes of all the other Participants and Endpoints in the Domain. This
information exchange is called metatraffic. Once remote endpoints have been discovered, the
local endpoints can be configured accordingly to establish communication. The discovery
protocol is divided in two layers: Participant Discovery Protocol (PDP) and Endpoint Discovery
Protocol (EDP). The PDP specifies how the Participants discover each other. Upon discovery the
Participants exchange information about their endpoints using the EDP. Different vendors may
implement multiple discovery protocols, however to ensure interoperability one PDP and one
EDP must be implemented by all vendors. These discovery protocols are called "Simple"
(Simple PDP and Simple EDP) and are very well suited for most applications.

The complete description of the discovery modules can be found in the specification document.
However the most important feature of this discovery mechanism is that it allows simple plug
and play connectivity, without the need of any configuration by the user.