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

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 https://mholdmann.wordpress.com/2013/05/11/iot-is-better-discribed-as-the-internet-of-nodes/ are accomplishing this with XMPP/ConnectingYourThings Platform.

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 i.e. 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.

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 ConnectingYourThings Platform 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 sensors) 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 ConnectingYourThings Platform.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.