Arm Community
Arm Community
  • Site
  • User
  • Site
  • Search
  • User
Arm Community blogs
Arm Community blogs
Internet of Things (IoT) blog IoT standards: How CoAP, OMALWM2M and IPSO smart objects fits together in an IoT stack
  • Blogs
  • Mentions
  • Sub-Groups
  • Tags
  • Jump...
  • Cancel
More blogs in Arm Community blogs
  • AI blog

  • Announcements

  • Architectures and Processors blog

  • Automotive blog

  • Embedded and Microcontrollers blog

  • Internet of Things (IoT) blog

  • Laptops and Desktops blog

  • Mobile, Graphics, and Gaming blog

  • Operating Systems blog

  • Servers and Cloud Computing blog

  • SoC Design and Simulation blog

  • Tools, Software and IDEs blog

Tags
  • smart
  • internet_of_things
  • objects
  • iot
  • Embedded
  • ipso
  • omalwm2m
  • coap
Actions
  • RSS
  • More
  • Cancel
Related blog posts
Related forum threads

IoT standards: How CoAP, OMALWM2M and IPSO smart objects fits together in an IoT stack

Pratul Sharma
Pratul Sharma
August 14, 2015
4 minute read time.

If you are following Internet of Things, you must have heard about CoAP, OMALWM2M, IPSO smart objects, etc. and have wondered how all these new protocols fits together in a stack. In this post we will look at how these protocols relate to existing world wide web and how they fit in an IoT stack.

Before we go into details, first let us look into the problems are we trying to address in the IoT space?

  • Interoperability- The way IoT devices are discovered, managed, data is reported and authentication is done should be interoperable. Ideally, any IoT device should be able to communicate with any web application or service.
  • Scalability: The interaction between the IoT devices and services should be scalable. Whether the devices and services are across the room or across the globe, whether there is one device or a million, software and standards should be able to scale as needed.
  • Re-usability: The software, networks and protocols should be re-usable across different applications and domains in IoT. In addition, vendors should be able to share a common software.
  • Innovation: The barrier to entry should be low. Anyone should be able to participate, innovate and create new IoT devices and applications.

Now if we look at the world wide web today, most of these problems are already solved.

  • In the world wide web, any web browser can communicate to any web service (up to a certain extent). It does not matter whether WiFi, wired Ethernet or Cellular modems are used for communicating the data.
  • Many different data models and content types are supported - streaming videos, flat web pages, images and dynamic web pages works seamlessly across different web applications.
  • Many different vertical application segments are supported – healthcare, retail, industrial, entertainment and the list goes on and on.
  • World wide web is already scaled to planetary size. The same software can be used for the communicating the data across the room or across the globe.
  • The barrier to innovation is very low. New web applications and services are coming up all the time. The cost of innovation is also low compared to other industries.

Let us look at how we achieved these qualities for world wide web.

  • Narrow waist architecture:  In the world Wide Web, most of the value is at the end points -  on one end we have web services and web applications, on the other end with have servers and the content. Everything in between is the communications infrastructure – the means to transport the data (the narrow waist).
  • Abstraction: The architecture is layered to provide abstraction. Layered architecture breaks up complex problem into smaller manageable pieces and allows abstraction of low level implementation details. As long as standard interface is maintained between the layers, different types of protocols and technologies can work together. For example,  Ethernet, WiFi or cellular modems can be used as a MAC layers with TCP/UDP for Transport layer. This abstraction provides world wide web architecture to scale for any number of applications.
  • Uniform addressing:  The resources are identified by a unique URI. No matter where the resource is on the web there is a URI to find it, and a hyperlink to point to it. This allows web browsers to interact with virtually any resource anywhere on the web and discover it. IP addresses and DNS names are globally unique to scale the web globally.
  • Statelessness: Statelessness means that the server stores the state and the clients are stateless. It allows large number of clients to interact with the a given server on the web, which immensely simplifies building applications and services.

So how can we apply these qualities in IoT?

By applying internet protocol on constrained devices, we can achieve same qualities in IoT as world wide web.

Let us look at the communication stack that enables IP to run on the constrained devices. Following figure shows the IP stack for the constrained devices and their non-constrained counterpart.

On the right, we have a communication stack for non constrained devices. HTTP is an application protocol running on IPV4 or IPV6. IP provides the addressing and routing. Below IP layer we can have WiFi or Ethernet for local network. The hardware, for the most part, runs  on microprocessors.  The equivalent stack for constrained environments is on the left. We have microcontrollers for the hardware which can be running some kind of low power, low bandwidth local area network, for example 802.15.4 provides low-power and low bandwidth network that can run on battery powered devices. Other examples are Bluetooth Low Energy or Thread (which actually runs on 802.15.4). The routing is handled by 6LowPAN which is a compressed header version and IPV6 that provides full IPV6 functionality on constrained  networks. For application layer, we have CoAP – Constrained Application Protocol – a light weight protocol specifically developed for constrained devices and machine to machine communication. It provides compressed binary mapping of REST API’s. Some additional features like Asynchronous notifications, CoRE link-format for hyperlinks are supported for machine to machine use cases.

Note that we can still use HTTP for less constrained networks.

We also have some common object models and data models for semantic interoperability. These models are used for exposing the resources in the IoT devices in a standard way. IPSO smart objects defines these models - a self-contained self describing objects that have URI and a well-defined schema. It is compatible with CoAP and HTTP.

For device management objects we have OMALWM2M protocol that is build upon CoAP. It defines simple reusable object models, REST APIs for on boarding and device life cycle management.

Other special interest groups like UPnP (Universal Plug & Play group), the industrial internet consortium, W3C  and the open interconnect consortium are also working on common data models and the “thing” discovery.

In summary, CoAP, OMALWM2M and IPSO smart objects provides a communication stack for IoT that enables interoperability, scalability, re-usability and innovation. Following figure sums up how above mentioned protocols maps in world wide web and internet of Things.

  

Anonymous
Internet of Things (IoT) blog
  • Transforming smart home privacy and latency with local LLM inference on Arm devices

    Fidel Makatia
    Fidel Makatia
    Learn how Raspberry Pi 5 and Arm-based local LLM inference can power a fully private, cloud-free smart home assistant with real-time performance
    • August 19, 2025
  • Building vision-enabled devices to capture the emerging wave in IoT

    Diya Soubra
    Diya Soubra
    IoT devices will drive an explosion in use cases with vision. Read more about the different use cases and what Arm technology is involved here.
    • December 9, 2024
  • The power of SystemReady for custom-built OS distributions

    Pere Garcia
    Pere Garcia
    Arm developed the SystemReady Devicetree band as part of the SystemReady program, learn more in this blog post.
    • November 22, 2024