Classification of IoT Devices

A typical architecture of an IoT solution consists of constrained devices, gateways or border routers and the cloud platform. On a high level architecture perspective there are two types of devices: constrained devices and gateway-like devices.

The gateway-like devices use powerful processors, extendable memories and no constraints on power source. They can route data to the cloud servers or aggregate/store data to deal with network latencies. Typically they run Linux operating system with application containers and provision for remote management.

The constrained devices are end nodes with sensors/actuators that can handle a specific application purpose. They are usually connected to gateway-like devices, low power lossy network, and in-turn communicates with the IoT cloud platforms. Typically they communicate via low power wireless protocols like BLE, 802.15.4 (6LoWPAN, Zigbee, Thread, WirelessHART etc), LPWAN etc and mostly battery powered with low data rate.


The constraints of these devices are

  • Code complexity (ROM/Flash), Size of state and buffers (RAM)
  • Processing power
  • Available power source and that has limits on reachability over time, if battery powered.
  • User interface and accessibility in deployment
  • Bitrate/Throughput
  • Highly asymmetric link characteristics
  • Cost
  • Physical size

In order to simplify the overwhelming variety of constrained devices that could be connected to the internet, IETF has published an RFC 7228 that classifies the constrained devices into three categories as shown in the table below.

Classes of Constrained Devices


Class 0: Class 0 devices have constraints in memory(<<10KiB of RAM and <<100KiB of Flash) and processing capabilities. These devices has severe constraints to communicate securely with internet, so they typically pre-configured and are connected to proxies, gateways, or servers for internet communication.

An open source IoT OS like Contiki takes around 8-20 KiB of RAM and ~100 KiB of flash. In table 1 and table 2, by Oikonomou, G et al, the code and memory footprint for various components of the Contiki operating system were listed. Table 1 consists of message generation and handling and does not include routing table processing or packet forwarding. So the complete stack (without security and routing) needs around 90 kiB of flash and 5.5 kiB of RAM. Enabling TCP  increases the code by 11 KiB and RAM usage by about 600 bytes.

Table 1


As the number of nodes increases, the size requirements for the routing and neighbour tables increases in Contiki. As shown in Table 2, it takes from 5.5 KiB to 9 KiB of RAM size.

Table 2


From the above tables, minimal network stack takes up most of the resources of class 0 devices and it is tough to fit anything more like security layer and application layer protocols like MQTT, CoAP, EXI etc

Class 1: Class 1 devices can have low power IoT stack [UDP, CoAP, leight weigh security protocols like DTLS etc] but quite constrained in code space and processing capabilities to employing a full protocol stack such as using HTTP, TLS, and related security protocols and data representations with out a gateway. 

Class 2: Class 2 devices are less constrained and can perform at par with mobiles phones/notebooks in supporting most the protocol stacks. They have to be lightweight with  energy-efficient protocols and less bandwidth consumption. Using Class 2 devices might reduce development costs and increase the interoperability.


1. C. Bormann, M. Ersue and A. Keranen , “Terminology for Constrained Node Networks”

2. Eclipse IoT White Paper, "The Three Software Stacks Required for IoT Architectures"

3. Oikonomou, G., Phillips, I., Experiences from porting the Contiki operating system to a popular hardware platform.

E-mail me when people leave their comments –

You need to be a member of CISO Platform to add comments!

Join CISO Platform

CISO Platform

A global community of 5K+ Senior IT Security executives and 40K+ subscribers with the vision of meaningful collaboration, knowledge, and intelligence sharing to fight the growing cyber security threats.

Join CISO Community Share Your Knowledge (Post A Blog)



CISO Breakfast at BlackHat Las Vegas 2024!

  • Description:

    We are thrilled to invite you to the CISO Breakfast at BlackHat 2024. 

    CISOPlatform is a community partner for the event which is co-hosted by Silicon Valley Bank, Stage One, First Rays Venture Partners, Latham & Watkins.


    Event Details: 

    • Date: Thursday, August 8th,…
  • Created by: pritha
  • Tags: blackhat usa, las vegas, ciso breakfast, usa