Going Mobile with Connext DDS 5.3

As The Who sang in their 1971 hit, we are “Going Mobile”. No, RTI is not moving its engineers to camper vans, we are referring to an exciting feature available in the newly released Connext^Ⓡ DDS 5.3!

Starting with Connext DDS 5.3, we’re introducing support for transport mobility, which will allow Connext developers to satisfy a lot of new IIoT requirements in some of the most challenging scenarios.

Mobility is a concept that is highly tied to IIoT: today's devices are becoming smaller, smarter, and are able to exchange data among themselves without the need of centralized servers. In addition to that, and, due to the reduced size of certain devices, they also have an interesting capability: the ability to change their physical location over time. That means, that as a device traverses different networks, the network address where a device can be reached may change over time.

For example, in a connected hospital, devices have to communicate within a patient room or operating room, to nurses’ stations and off-site monitors, to real-time analytics applications for smart alarming and clinical decision support, and with IT health records. In addition, there are security requirements relating to patient data as well as the need for all of the data to be available in order to determine what the next move might be in the patient’s treatment. Now ask yourself: what happens when a patient moves from the operating room into a recovery room? What happens when a machine is swapped out or new sensors are added? How do we ensure that even though devices might be changing IP addresses, all of the patient’s data remains available? This is a highly technical challenge since the handoff between networks should be transparent, fast and without loss of data. In 5.3, we’ve addressed this and made it easier for system architects to ensure the reliability and security of their connected systems.

In previous versions of Connext DDS, this mobility scenario was not supported. Once an RTPS entity was enabled, it was assumed that it would be reachable over the same network addresses during its entire lifetime. This assumption meant that, if an entity was moved into a different network or the network address associated with an interface changed, it may become unreachable for all the counterparts that already had discovered it.

Starting in Connext DDS 5.3, this assumption is no longer true. Now you will be able to change network addresses of Connext DDS applications at run time without the need to restart them. This new feature will enable a number of new use cases:

• Starting a Connext application without network connectivity and connecting to the network at run time
• Switching network interfaces, such as going from wired to WiFi
• Acquiring a new IP address after DHCP lease expiration
• Enabling mobile devices to roam across network segment

How transport mobility works

During the discovery phase of a DDS application, DDS DomainParticipants announce the network addresses and ports (locators in RTPS terminology) where its RTPS endpoints (DataReader/DataWriter) can be reached by other remote endpoints. For instance, a DataReader may announce that it is reachable at network address x.x.x.x:yyyy. In previous versions of RTI Connext, those locators were considered to be static: the locators announced by a certain RTPS endpoint at the beginning were assumed to not change over the RTPS endpoint lifetime.

Imagine a host with one network interface and network address 10.10.0.120 that starts a DDS DomainParticipant with one DataReader. When this DataReader starts, it announces that it is reachable in the address 10.10.0.120:7014. From this moment, every DataWriter that discovers this DataReader will send data to this DataReader using RTPS messages directed to the address 10.10.0.120:7014. Now imagine that this host is moved to a different network (e.g., 10.20.0.X) and gets a different network address (e.g. 10.20.0.153). All the DataWriters that already discovered it, will continue trying to send data to the DataReader using the old network address (10.10.0.120), but this DataReader is no longer available in this network address. As a consequence, all new messages will be lost, and after liveliness loss is detected, the RTPS endpoints will be unmatched.

From the previous description, we identify a couple of things that need to happen in order to support mobility:

• First, the middleware/application should be able to detect when any of the addresses associated with its network interfaces change, for instance, if an interface is added, removed or the network address associated with an interface changes for any reason (e.g. DHCP expiration).
• When a change on the network interfaces happens, the list of the new addresses associated with this host should be propagated to all potentially interested parties. This way, applications can know where to reach the applications associated with that moving host.

In this version of Connext DDS, we have added the necessary functionality to implement mobility. This is how the whole process works:

• When an Connext DDS application is started, it announces the locators where the RTPS endpoints (DataReaders and DataWriters) can receive data using the discovery protocol.
• The Connext DDS is continuously tracking the network interfaces for changes in their network addresses.
• If a change in any of the network interfaces is detected (e.g., there was a change in the network address associated with an interface or it was torn down), an updated list of locators associated with RTPS endpoints present in the application will be announced using the discovery protocol.
• When another Connext DDS application receives a discovery message containing an update on the locators associated to certain RTPS endpoint, this application will update its internal database and will start using the new locators to reach the RTPS endpoint.
• If DataReader is configured with reliable reliability, Connext DDS will recover automatically using the regular reliability protocol from any potential sample lost while it was not available.

That's really cool!  How I can start using it?

The good news is that this feature is available out-of-the-box in RTI Connext DDS 5.3. No need to setup or configure any special QoS settings. Connext DDS is going to detect and propagate network setting changes at run time without any user intervention. Currently, Connext DDS transport mobility is supported for the following transports: UDPv4, DTLSv4, UDPv6, TCPv4, TLSv4, LBRTPS and ZRTPS.

For more information about this feature, check the RTI Connext DDS 5.3.0 What's New document. 

Now you are ready to go mobile with RTI Connext DDS!