Objects and Federation for Inter-domain Communication in IoT and M2M

Published: Wed 05 Jun 2013
A blog entry by Michael Holdmann

Contributed by:

Michael Holdmann
EVP | Strategy | Alliance
Coversant, Inc.

Michael Holdmann's Blog

For M2M and IoT there are two options to accomplish the feat of one platform to manage and federate multiple domains using XMPP.

Both examples I listed in the original discussion post http://mholdmann.wordpress.com/2013/05/11/iot-is-better-discribed-as-the-internet-of-nodes/ are accomplishing this with XMPP/SoapBox.

Option 1- Current legacy infrastructure

Current infrastructure in most cases uses a building controller, this controller allows you to maintain eyes on numerous different data communication protocols (bacnet, Lonworks etc.).  Each similar device though, connected to the controller, does have the same values (a fan 3 data points/properties with multiple possible values per point ie 1=On/Off, 2=Forward/Reverse. 3=Speed) no matter what the language, data protocol or manufacturer of the device.  Some data communications protocol drivers already have objects built into them, as the ones mentioned above do, for others the uncomplicated but tedious task of building the objects is required.  With XMPP you build a simple app that reads the object (values), once built it can be used on any XMPP server, due to open standards, and send data of object value that is acting out of norm by placing a client on the controller and communicating the data to one, few, many or all other endpoints; man, machine, application, database.  So you do have multiple domains in service in buildings not only between different systems; HVAC, Alarm, Power monitoring, Security, Close circuit video (CCTV), Card and keypad access, Fire alarm system, Elevators/escalators, Plumbing and water monitoring but different protocols for like systems.  You also have domains outside the buildings that need to know only the information that is pertinent to them.  This is accomplished by creating persistent connections with control and forwarding in Layer 7, certs on both client and server or server and server and channel binding.

There is a great real world example of the federation of 9 domains and sending of real-time presence information with the US Air force on YouTube entitled SoapBox, World Wind and Red Flag [youtube=http://www.youtube.com/watch?v=Or0IQxn0kTE].  SoapBox was used in C4 of each country which were federated in a Multi User chat, all information on telemetry, altitude, acceleration, positioning, fuel, weapons status and other information necessary was sent to the countries that need to have the info even though all the countries were in the same room via SoapBox.  The colored overlay on the operators screens is how Soapbox was integrated in NASA WorldWind and operations could now identify each countries asset, not easily accomplished before, creating a much more dynamic, efficient and  secure operating environment.

Option 2- IoT, new smart device deployment

The devices, not all necessarily smart (a temp gauge will never need to be smart, it is only sending one value- temperature), have either an XML parser and TCP/IP (around 40k) running on the device and they can communicate within the node and talk to the SoapBox local server or an XMPP client (around 1.5mb) loaded on smart device either in a node or as a standalone in metro areas for example (traffic camera, chem/bio/rad senors) or rural areas (oil/gas rigs, pipelines)  and be connected to the domain through the internet with all the added benefits of the layer 7 control and forward as well channel binding to mitigate man in middle attacks.

I hope this gives a better idea of what is possible today with XMPP and the SoapBox efficiencies and performance