WHITEPAPER

Limited-Bandwidth Plug-ins for DDS
INTEGRATING APPLICATIONS OVER LOW BANDWIDTH, UNRELIABLE
AND CONSTRAINED NETWORKS USING RTI CONNEXT DDSThis paper describes a number of additional capabilities RTI
has created for its OMG® Data Distribution Service (DDS)
compliant connectivity framework, specifically to address
the challenges of constrained network communication. It will
discuss some sample network types and present solutions
using RTI Connext DDS.
We define “constrained” networks as having one or more of
the following characteristics:• Low bandwidth – for example, HF radio links often have
speeds as low as 1200 baud
• Limited bandwidth – where it is known ahead of timethat peak traffic loads will exceed available bandwidth.

• Simplex – HF radios commonly cannot detect incoming
signals when they transmit, so if more than one
transmits at a time nothing gets through and noneof the radios can detect that issue
Three optional modules available for RTI Connext DDS aredescribed in this paper:• Compression• Optimization of the DDS wire protocol (RTPS)• Enhanced discovery, optimizing application boot timeover the network• This requires bandwidth management combined withimproved wire level data transmission efficiencies.

ASSOCIATED APPLICATIONS• Very high signal latency – for example, satellite links
can have high bandwidth but also very high latency
for round trip communications. High frequency radios
commonly have very high latency, too.

The technology described in this paper is applicable tomany different types of applications. Applications commonlyrequiring these sorts of features and capabilities include thefollowing. Please visit www.rti.com for additional details andcase studies.

A network or its communications links may be constrained inother ways, such as:• Highly error prone – sometimes referred to as DIL(Disconnected, Intermittent, Limited or Lossy) networks,
such as radio data-links to Unmanned Vehicles• Variable bandwidth – modern HF radio connections
respond to varying noise levels by dynamically adjusting
to appropriate waveforms and forward error correction
techniques that may vary bandwidth• Advanced Combat Net Radio systems• Asset Tracking systems• Air Traffic Management Systems• Unmanned Systems• Wide Area Network based applications suchas those using satellite communications• Receive only - sometimes referred to as EMCOM(Emission Control) in defense, whereby a receiver
does not wish to broadcast, usually in order to avoid
location detection

BACKGROUND INFORMATIONThis paper assumes a reasonable level of understandingof the principles of DDS. For more information on DDS,
please visit www.rti.com or www.omgwiki.org/dds/.

rti.comWHITEPAPER • LIMITED-BANDWIDTH PLUG-INS FOR DDS

THE CONSTRAINED NETWORK PROBLEM
Whether your planned network has low or limited bandwidth,
high latencies or all three, the additional requirement on themessaging middleware layer is to place the minimum strain
upon the communication links. This is usually expressedin terms of even more efficient messaging mechanisms,
minimized packet overheads and maximized data to packet
size ratio.
MAXIMIZED DATA TO PACKET RATIOThe DDS Wire protocol was designed for distributed real-time
applications. It was therefore designed from day one to behighly efficient on the wire. For example, data type information
is exchanged once at discovery time, not continuously at runtime. In addition, the open OMG standard wire protocol of DDS(called the DDS-RTPS Interoperability Wire Protocol) uses avery compact and efficient binary wire data representation(Common Data Representation—CDR). RTI has numerous
benchmarks that support its throughput capabilities(see www.rti.com/products/benchmarks).
The application developer is also given fine grain control ofpacket sizes, which is particularly important in low bandwidthand high latency networks where application data needs tobe placed into large data packets to minimize the impact oflatency on the application. RTI Connext DDS also uses type
information intelligently in order to put minimum data on thewire. For example, it supports sparse data types so that only
those fields of a type that have changed are transmitted on thewire. For more information on standard product capabilities
see www.rti.com/products.
OPTIMIZING PACKET SIZE ON THE WIRE
As mentioned earlier, DDS uses a standard on the wire protocolcalled RTPS. This open wire protocol is designed to guarantee
interoperability between vendor implementations of DDS
and is versatile enough to run over many types of transportand evolve over time without breaking interoperability with
deployed systems. Although RTPS is already highly efficient
for real-time networks, it does include a 20 byte packet header
designed to meet the needs of a wide variety of network
types, a 12 byte timestamp, and an additional 24 byte submessage header that precedes each data payload. The data
overhead these 56 bytes introduce is usually insignificant
for high-speed networks (indeed, it is very efficient whencompared to most other messaging middleware). However, its

impact on throughput increases as bandwidth or bandwidthavailability reduces.
The packet headers contain information that can be optimized
if the application is running over transports that are extremely
low bandwidth, where every bit is precious; in small networks
where addressing requirements are minimized; or in highlatency environments where certain types of time oriented
information become irrelevant and unusable at the application layer.
For network transports using UDP/IP, RTI has created aneven further optimized version of RTPS that enables thedeveloper to strip out certain header information for networks
and applications with the aforementioned attributes. Theconfigurable options enable up to 30 bytes to be stripped outof the typical 56 byte standard RTPS header. For example,the RTPS GUID (Global Unique Identifier) is a 12 byte field
consisting of 3 fields of 4 bytes each. The first is an address
field, which in most networks is masked down to the lastbyte (for example in an IP network the address mask might
be 192.168.1.x) and can therefore be reduced to 1, 2 or 3
bytes depending on your IP address mask. The second is alocal application identifier (within the computer at that IPaddress), but many distributed real-time systems run a single
application on each computer, so this field can be ignoredand defaulted to 1. In addition, a participant index is used toidentity multiple DDS participants on the same computer.
However, many applications running on radios or other highlyconstrained devices have only one participant per node, soagain this field can be stripped out. Overall this RTPS, 12 byteheader field can be reduced down as low as 1 byte.
Using similar logic, up to 18 additional bytes of information
can be stripped from the header without reducing the utilized
functionality of DDS at all. Removing this packet content candeliver a 53 percent efficiency saving on the packet overheadof the standard RTPS protocol.
RTI’s optimized wire protocol can be layered with thecompression plug-in to create a powerful combination ofoptimizations for constrained or low bandwidth and/or highlatency networks. However, to fully optimize messaging
middleware for these sorts of networks, we need to optimize
the way DDS itself works, in particular its discovery operation.
PACKET COMPRESSION
When the network link is very low bandwidth or alreadyclose to its capacity, application-specific efficiencies may
be sought. Compression is a common approach to address
the issue, but it comes at a cost in terms of CPU use andlatency. The time taken to compress a packet will add to thelatency of the communication. In many systems, the available
processing power versus the available bandwidth is a simple
trade off to make: the latency in low bandwidth networks isoften high anyway, so the proportional impact of compression
can be minimal. This is certainly true in high frequency radio
networks, where latency is measured in seconds. In addition,
on today’s low cost and high performance processors,even the most comprehensive compression techniques willtake milliseconds. On more powerful processor platforms,
compression offload engines may be available to minimize
latency impact even further.
RTI has developed a compression transport plug-in that
addresses all of these issues and more. Compression

2 • rti.com

WHITEPAPER • LIMITED-BANDWIDTH PLUG-INS FOR DDS

algorithms work at varying levels of efficiency dependent on
the size and type of data being compressed (images versus
text, for example). As DDS gives fine grain control overpacket sizes to the application, it becomes very beneficial if
the compression plug-in provides flexibility to control whichalgorithm it applies to which packets. This plug-in allows you
to define three packet sizes—small, medium and large—with
your own size parameters. You can then assign a compression
algorithm to each packet size.
Alternatively, if you have processing power or latency tospare, you can have the plug-in run in an automatic selection
mode. In this mode, all compression algorithms run in parallelfor each packet and the best result is selected to send thepacket to the underlying transport.
The compression plug-in comes with two integrated
compression algorithms as well as facilities for users tointegrate their own compression algorithm:• Open Compression Plug-in: a framework fordevelopers to integrate their own compression
algorithm or algorithms• Zlib: an abstraction of the DEFLATE compression
algorithm used in gzip
• Bzip2: a lossless compression algorithm which,depending on the data, can be far more effectivethan Zlib but takes approximately 12 times longer
on typical data
The flexibility of the Compression Transport Plug-in combinedwith the inherent fine grain data communication capabilitiesof DDS enables users to fine tune the bandwidth utilizationand latency to best meet their distributed application
requirements.
EFFICIENT DATA DISTRIBUTION
This paper does not go into depth on the general featuresof DDS that enable application developers and systems
integrators to make the most efficient use of their underlying
transports. However, we will briefly summarize some ofthose DDS and RTI Connext DDS features that tend to be ofimportance to application developers in constrained networks:• Multicast support - static multicast (multicast
address IP assigned to a fixed set of recipients)
and dynamic multicast (each sender has a set of IP
multicast addresses reserved for dynamic multicast
to allow negotiation of the multicast recipients).
DDS makes no distinction between these and pushes
the exact methodology down to the transport level
implementation.
• Message prioritization – can be a key issue especiallyin high latency networks. DDS supports several Qualityof Service (QoS) features such as TransportPriority
and LatencyBudget that enable fine grain control ofprioritization of bandwidth utilization to take advantageof the underlying network infrastructure provides.
• Latency-aware packet batching – is particularly
important in high latency networks. This is transparently
supported by RTI Connext DDS and configured by
setting a QoS.

• Multiple transport support – DDS supports packet
sequencing. So if you have multiple connections
between two nodes (an HF radio and a satellite link forexample), you can transmit on both and the recipient
will ignore packets already received.
• Flow control – RTI Connext DDS allows applications toconfigure the shape of the traffic load the middleware
places on the network, limiting maximum throughput,
peak bursts, etc. It also allows applications to tag
different data-flows with their relative latency needs
so that the middleware can police the access to thetransport and ensure that the most urgent traffic
gets precedence.
Of course, any messaging middleware has to discover andset up communication paths between its active participants.
How efficiently this is done is important to any network at startup, but it’s critically important that this is achieved optimallyin low bandwidth and high latency distributed systems.
DDS DISCOVERYA key attribute of RTI Connext DDS is its inherently fault
tolerant and distributed system friendly design. It not only
tolerates any node failing at any time, but also enables network
nodes and applications to start up and terminate (plannedor unplanned) in any order at any time across a network oron a single computer. It even caters to incremental version
upgrades of DDS on live networks. All of these capabilities
are under-pinned by the DDS-RTPS protocol and Discovery
mechanism.
This fault tolerant integration flexibility requires DDS todiscover each publish-subscribe communication channel
between participants. DDS typically supports a completely
anonymous publish-subscribe environment, where noknowledge of any part of the application is known aheadof time in order to facilitate integration in highly dynamicenvironments. Each participant merely knows that anotherparticipant somewhere may be able to meet the data needs
it has or may be interested in the data it has and how it canbe provided. This means any deployed distributed system
can be changed, added to, or reduced in terms of active
participants—without recourse to re-builds, recompilation oreven re-starts of any other part of the system.
To support this capability, each participant maintains a local
knowledge cache of other participants in the domain andtheir entities. To maintain their presence in the distributed
application, participants must refresh their presence in thedomain or they will be aged out of the cache. To sustain thecache, participants announce their presence at a period set
up at the application layer. Participants may also change
their QoS as well, and this information may need to be
propagated, too.
For most networks, this overhead is minimal, fairly steadystate, and does not have any significant detrimental effecton the application performance or network throughput.
However, in low bandwidth and/or high latency networks,
this can consume enough bandwidth to have a noticeable
effect on the applications in terms of the time it takes for thecommunication infrastructure to be set up.

3 • rti.com

WHITEPAPER • LIMITED-BANDWIDTH PLUG-INS FOR DDSINTRODUCING QUASI-STATIC DISCOVERY
To meet the challenges of the low bandwidth and/or
high latency over DIL type networks, RTI has created a
discovery plug-in that enables highly efficient utilization ofavailable bandwidth.
One key design issue that distributed application developers
need to consider is the nature of application presence.
DDS typically makes no assumptions at all about the set ofapplications that may or may not be present on the network at
any time nor about how that application is distributed acrossthe network. Hence, discovery works in the background tocontinuously maintain address tables and resolves publishsubscribe QoS negotiations. However, in many deployedsystems, the application or set of applications may be known
ahead of time and will not change while the network is inservice, nor will the QoS parameters vary – the application
presence is pre-determined and stable. The order of nodeand participant start up may still be arbitrary, and nodes andparticipants may often fail, become inaccessible, or otherwise
need a fall back node or participant to continue the application.
The quasi-static discovery plug-in of RTI Connext DDS uses
these assumptions to achieve a highly optimal discovery
phase for DDS which is particularly beneficial in constrained
and low bandwidth networks or networks requiring very fastboot up.
PRINCIPLES OF QUASI-STATIC DISCOVERYThe DDS discovery process is executed in two stages. Thereis a DDS Participant1 discovery phase and a DDS Endpoint2
discovery phase. With quasi-static discovery, the second
phase is suppressed, and is replaced by an XML file that acts
as a look up table. When a DDS Participant announces it hasjoined the distributed environment, RTI Connext DDS looks
up the set of end-points that must now exist and establishes
the publish-subscribe communication channels. No QoS
negotiation is needed because this has already been validated

1
2

in the development environment and is part of the XML lookup table, further reducing traffic on the network.
The net effect of this optimized discovery is a significant reduction in the time taken to establish channels of communication in systems in which application constituents are known apriori, while maintaining DDS’s robustness in DIL environments.
QUASI-STATIC DISCOVERY PERFORMANCE
In early tests on a 2400 baud HF radio network of 8 nodes(1 participant per node), quasi-static discovery reduced
discovery time (and thus application set up time) to lessthan 40 seconds. To put this in perspective, for 8 nodes tosimultaneously start up and seek to set up their connections
over a 2400 baud HF radio network means that each radiohas 300 baud available to it. However, due to collisions andother issues in HF radio, you end up with a more realistic 150
baud connection—in other words, an effective throughput of
18 bytes per second. So, a complete 8 node application-levelmessaging framework with one publisher and one subscriber
per node is set up by quasi-static discovery through thesuccessful transmission of under 6000 bytes of information!
These tests were made on the Thales PR4G Combat Net radio.
This HF radio system is widely adopted across many nations
for portable infantry tactical radio requirements.
SUMMARY
DDS has proven its applicability to challenge DIL distributed
environments with its successful deployment in many
tough environments. With the addition of compression,an optimized wire protocol, and quasi-static discovery,
customers of RTI Connext DDS can now confidently apply
this resilient integration middleware to highly constrainednetwork environments.

A DDS Participant is a process which may or may not be on another node
A DDS Endpoint is a publisher or subscriber contained within a DDS Participant

ABOUT RTI
Real-Time Innovations (RTI) is the Industrial Internet of Things (IIoT) connectivity company. The RTI Connext® Databus
is a software framework that shares information in real time, making applications work together as one, integrated system.
It connects across field, fog and cloud. Its reliability, security, performance and scalability are proven in the most demanding
industrial systems. Deployed systems include medical devices and imaging; wind, hydro and solar power; autonomous planes,trains and cars; traffic control; Oil and Gas; robotics, ships, and defense.
RTI lives at the intersection of functional artificial intelligence and pervasive networkingSM.
RTI is the largest vendor of products based on the Object Management Group (OMG) Data Distribution Service™ (DDS) standard.
RTI is privately held and headquartered in Sunnyvale, Calif.
Download a free 30-day trial of the latest, fully-functional Connext DDS software today: https://www.rti.com/downloads.
RTI, Real-Time Innovations and the phrase “Your systems. Working as one,” are registered trademarks or trademarksof Real-Time Innovations, Inc. All other trademarks used in this document are the property of their respective owners.
©2018 RTI. All rights reserved. 50012 V6 0119

CORPORATE HEADQUARTERS

232 E. Java Drive, Sunnyvale, CA 94089
Telephone: +1 (408) 990-7400
Fax: +1 (408) 990-7402
info@rti.com

4 • rti.com

rti.comcompany/rti

rti_softwareconnextpodcast

rtisoftware

rti_software