Deconstructing the IoT Reference Model

Deconstructing the IoT Reference Model

The Internet of Things, or, IoT is a fast growing area of technology.  It is widely talked about but along with it there is a tremendous amount of misconceptions, confusion and lack of understanding as to what really constitutes IoT. 

The IoT World Forum took a stab at bringing some order to this chaos through its Internet of Things Reference Model.  Whether one agrees or disagrees with the Reference Model and its 7 layers as shown in the diagram above, it does enable one to “bucket-ize” various activities within the IoT Ecosystem.  It also enables one to have meaningful dialog over the various activities and how competing platforms stack up.  For competing technologies it enables an apples-to-apples comparison for interested parties.

Let us examine each Layer in greater detail. 

  • Layer 1: Physical layer of sensors, beacons & controllers. In many cases the hardware specified in this Layer can consist of off-the-shelf general purpose components e.g. Arduino, Raspberry Pi and the like.  However, in several more complex implementations, one has to develop custom IoT hardware that maps to peculiar needs to solve the problem at hand.
  • Layer 2: Often this takes the form of moving data from the physical devices to either the cloud or other device. For connectivity to devices nearby this could take the form of Zigbee, ZWave, SigFox or Bluetooth(Regular and BLE).  For cloud connectivity, it could be wired or wireless using 3G, 4G.
  • Layer 3: Edge Computing. This is the future and companies like Cisco are pushing the concept of Fog Computing. The general idea is to make devices at the periphery of the network more capable and intelligent instead of being too reliant on the cloud.  With billions of smart devices expected to be in our midst, there has to be a balance in computing power between the edge and the cloud. 
  • Layer 4: Data Accumulation. When data gets accumulated, it needs to be stored somewhere. Now, while some limited amount of data can be stored at the edge, a bulk of this data needs to find its way to the Cloud in order for the heavy lifting of the Big Data machines and their computing power and analytical prowess to take hold. 
  • Layer 5: Data Abstraction. This is the layer I would is arguably the most debatable in terms of its naming.  Basically, IoT systems has two broad types of data.  Configuration data and Live data.  Configuration data is the metadata about the system, its devices setup info, access control info and more.  It is more or less static in one sense.  Since IoT when deployed is a Real Time system, the other component is the Live data that it collects or emits through the various devices in Layer 1.  This Live data has to be stored (Layer 4) and aggregated or inspected for visualization or real time decision making. 
  • Layer 6: Application. Again, the wording from the Reference model is somewhat subjective.  It does not clearly delineate the audience for the Application. The audience of an application can be the administrators or the end consumers. One may need an Admin Panel, for administrators, that provides a viewport into the Live Data and Configuration data in the System.  The may also be an end-user application.  Either way, these applications will tie into Layers 5 and 4 to access and manipulate data.
  • Layer 7: Collaboration and Processes – In many commercial and industrial applications of IoT, the data collected has to be acted upon. How does that happen? Well, one needs to have a Workflow and Rules to route incoming messages from devices to the appropriate audiences under the appropriate conditions.  g. “if fire sensor is ON, make automated call to Fire Department”. 

IoT is a complex set of technologies, and the IoT Reference Model helps create structure around a subject that is growing in several different directions. 

Thanks Ed. So, there are already examples of edge devices talking to one another. For instance, if you consider Sonos devices for Home Entertainment. They have a controller and satellite devices which communicate with each other over a mesh network and then communicate with the cloud over Wifi.

Great summary! I hadn't given thought to Layer 3, but it makes sense in terms of some processing speed gains as well as backup processing in the event there is a disconnect from the network. Is this also where you may have devices communicating with each other vs. through the cloud as an intermediary?

To view or add a comment, sign in

More articles by Raghu Bala

Others also viewed

Explore content categories