Site Tools


OCF CoAP Native Cloud 2.0


What are the biggest problems in IoT? Where do current market IoT solutions fall short? How should IoT be considered? [2018]

Put another way, “What are the most common issues preventing companies from fully realizing the benefits of IoT?” This question was answered at DZone by 23 executives involved with the Internet of Things.

Most important observations:

  • Companies are not able, or do not have the talent, to complete the end-to-end solution.
  • The unrealized complexity of deployment and the lack of skills to do so.
  • Lack of seamless and secure data fabric platform.
  • Challenging to make something at scale while maintaining quality.
  • Creating scalable devices that connect to everything they need to.
  • Large amount of the data that will run the IoT will be stored in the cloud.

The IoT industry, across numerous market verticals, is at an impasse where customers are demanding increasing sophistication at lower prices. Given the complexity and importance of IoT, no single company can or should be dictating the path forward for the entire industry.

The only viable path forward is collaboration between companies and market verticals to collaborate on developing, testing and standardizing the non-differentiating functionality. The Open Connectivity Foundation is currently working to achieve that, however the device-cloud communication represents a unique challenge for the engineers involved because there has never been a historical need for engineers to become knowledgeable in both embedded systems and cloud native application development. The proposed solution to this problem is to emulate the container runtime interface (CRI) architecture and embody Conway’s law to establish a loose coupling between the “IoT code” (CoAP/iotivity cloud interface) and the portions of the system that are much more familiar to the cloud developers (ex: db/messaging/auth) which will also vary more depending on the use case.

<WRAP center round info 90%> “Throughout our history, it has always been standardization of components that has enabled creations of greater complexity” –Simon Wardley </WRAP>

Most important challenges

  • Embedded systems engineering and cloud native application development are likely orthogonal skill sets for the organizations whose products would benefit the most from internet connectivity
  • The immense complexity of managing your own deployment means the market requires managed services
  • There is no seamless portability for IoT devices between clouds
  • Extremely important if we want to decouple the networking costs from hardware costs for customers, like we do for cell phones
  • Lack of an industry standard IoT cloud increases the attack surface of the industry

Design goals

  • Address these challenges in a way that is easy for companies and public clouds to adopt and offer as a managed service
  • Ensure a loose coupling between the database / messaging / auth and the OCF Native Cloud reference implementation
  • Provide an “official” backend that demonstrates how to integrate the database / messaging / auth and serve as the default choice for companies with common OLTP use cases

Domain Overview

<WRAP center round info 90%> The Internet of Things (IoT) is the network of physical devices, which are embedded with electronics, software, sensors, actuators, and connectivity for the purpose of enabling these things to connect and exchange data. Thus creating opportunities for more direct integration of the physical world into computer-based systems, resulting in efficiency improvements, economic benefits and reduced human intervention. (Wikipedia, Internet of Things) </WRAP>

In other words, an IoT device is regularly subject to change, since it represents the world around itUnderlined Text. It's up to the developer, how the world is represented through the device and processed by the application for your specific domain. Technology should support the transfer of data in a standardized and secured way. The IoT platform can't limit you and can't set boundaries, which would limit evolution of your system.

Domain is a sphere of knowledge, influence or activity.

IoT itself is most likely not a domain of your business, it is a group of technology achievements from the last decades of the 20th century, which open the door to new possibilities for your business domain. Allowing for the modelling of the external world specific to your needs, in the form of resources and events, which will be transferred in a secure and traceable manner to your application, located off-premise or even on-premise. The goal is for developers to focus primarily on the domain of their business.

Architectural drivers & Patterns

<WRAP group> <WRAP half column>

Technical Constraints

  • CoAP
    • OCF mandates CoAP support for compliant devices.
  • CoAP over TCP
    • While UDP may be preferred for messaging over local networks where “chattiness” is highly detrimental due to power or bandwidth constraints, CoAP over TCP is preferred for situations where a device is communicating with a remote server due to the greater QoS guarantees and TCP has substantially better support than UDP in cloud native use cases.
  • TLS
  • CBOR
    • Default media type used in communication between OCF compliant devices and components is CBOR. It has to be supported by default.


<WRAP half column>

Quality Attributes

  • Scalable
    • A forecast provided by Ericsson states that there will be around 18 billion IoT devices online in 2022. The system needs to not only be able to handle large scales, but also be able to rapidly scale up and down in response to load.
  • High Availability
    • IoT devices are often crucial to the safety and performance of the system that they’re used in. While these devices may be in inherently low QoS environments, it is the responsibility of the cloud to always be available when the devices need it and otherwise not be the weakest link.
  • Traceable
    • Many users and devices at once can bring a lot of business errors to consuming systems. It is beneficial to track activities within the system for better error solving and future prediction based on similar periodic patterns.
  • Cost Efficient
    • Many future users won't have the knowledge about infrastructure and operations of the whole system. They might not have their own data center for hosting of the solution. This increases the importance of ease of use and cost efficiency. Most cloud providers offer a similar set of services from a functional point of view. A solution should be able to take advantage of these services to save money, alleviating the burden of missing know-how and increasing runtime optimizations.
  • Multitenant
    • Solution providers which have multiple customers should have the ability to use “one” instance of the system for all customers in a secured way. It is important that a client is only able to access the devices it’s authorized to access.



Missing events, delays, invalid values, unreliable networks, depleted batteries… An IoT device is unreliable by nature. It's exposed to the real world, and your system has to account for that. Depending on the domain, many compensations might be expected within your system. That's a risk you face when dealing with the outside world from your warm silicon farm. Retroactive Events and Parallel Models are challenges you will face. In such a case, it might be important for you to know what led to a certain state, reproduce it event by event, debug it or just explore the path leading to the state.

Quality drivers, domain, and other IoT related facts are calling for CQRS and Event Sourcing patterns.

<WRAP center round info 90%> Using the OCF Native Cloud does not force you to use Event Sourcing throughout your whole system. Actually, doing so would be a bad idea. </WRAP>

Decomposing the Domain (Bounded Contexts)

<WRAP group> <WRAP half column>


Servers (IoT Devices) which are OCF enabled are represented in the form of resources. (similar to REST) Resources are hosted by a server and if it is connected to an OCF Native Cloud, it is able to publish those resources, which should then be accessible “remotely” through this decentralized component. That means, the OCF Native Cloud works both as the gateway and the resource directory for all connected and authorized servers / clients. If the connected client wants to find a specific resource hosted by a specific device (resource directory) and CRUDN that resource hosted by that server (gateway), OCF Native Cloud will take care of it.

<WRAP center round info 90%> To understand more about what a resource is, read chapter 7 - Resource model </WRAP>

Connected server / client can:

  • Publish / Unpublish resources
    • A resource is represented by a URI and properties (resource types and interfaces)
  • Find Resources
    • Find resources published by servers to the Resource Directory
  • Read Resource Shadow
    • Resource Bounded context keeps up-to-date representation of each remote resource
  • Update resource representation
    • Resource Bounded context propagates each update to the device's resource


<WRAP half column>


EEvery client (application interested in data) connected to a server (IoT Device) should be able to perform an action on the device or access data published by that device (resource directory), if authorized. That means, not every connected client and server should be able to find / CRUDN any resource published to the Resource Directory.

When the server / client are connecting to the OCF Native Cloud, these entities are required to successfully sign-in and sign-up. Only after a successful sign-in operation they are allowed to use the Resource Directory - Resource Bounded Context.

<WRAP center round info 90%> As detailed in this specification, token based authorization should be used. </WRAP>

During the sign-up process, which can be thought of as a registration, a one time use authorization code is verified by the Authorization entity and the access token is issued by the Authorization entity. This token is then used exclusively by this server / client pair and uniquely represents this pair in the OCF Native Cloud.

The connected server / client has to belong to the user of the Authorization entity, which requested the one time use authorization code. When an access token is retrieved by OCF Native Cloud from the Authorization entity, it will register that device locally and link it with that user - or specific attribute of that user, for example tenant id.

An example to make it more clear (Note: this is not a complete workflow, there are some missing attributes, but as this bounded context is about authorization, it's skipped for ease of reading):

  • GitHub user A authorized GitHub App OCF Native Cloud and received one time use authorization code
  • User A set this authorization code locally to the device (through NFC for example)
  • Device (server) connects to the OCF Native Cloud and performs sign-up
  • OCF Native Cloud will contact GitHub and ask to exchange authorization code with access token (if valid)
  • Returned access token (jwt) contains id of the GitHub user, which is used as server / client “owner identifer”

Then an owner has access to only their devices. In this example, that means user A can access, by default, only devices registered through the user A's account.

Connected server / client can:

  • Sign-up
    • Registration to the OCF Native Cloud with valid authorization code
  • Sign-in
    • Authorize connection based on provided access token
  • Sign-out
  • Authorize
    • Resource Bounded context operations have to be authorized
      • Server / Client must have access to server hosting the resource


Resource Bounded Context

Domain definitions

The following list defines the key domain-related terms.

  • Client is a logical entity that accesses a Resource on a Server.
  • Resource is an object with a type, associated data, relationship to other Resources, and a set of methods that operate on it. It is hosted by the Server.
  • Resource Directory is a set of descriptions of Resources where the actual Resources are held on Servers external to the Device hosting the Resource Directory, allowing look-ups to be performed for those Resources.
  • Resource Shadow is the latest state of the Resource stored directly in the OCF Native Cloud, which is eventually consistent with the state on the device.
  • Resource Type is a uniquely named definition of a class of Resource Properties and the interactions that are supported by that class
  • Server is a Device with the role of providing resource state information and facilitating remote interaction with its Resources.

Requirements for working with resources

A server hosting resources has to be accessible through the OCF Native Cloud. After successful connection, authentication and authorization, the server has to publish its resources, which are discoverable by other connected and authorized clients and servers. Clients should then be able to discover resources based on resource type or by the identifier of the server which is hosting them. A client should also be aware of the information, if the server hosting resources is online and the client performs CRUDN operations on resources published to the resource directory. Requests should be consumed by the server hosting the resources (*), and the client informed of the result.

(*) In case of the OCF CoAP Gateway, through which servers are connected to the OCF Native Cloud, commands should be consumed and processed by the gateway where the requested server is connected.


  • Before a client can look for a resource in a resource directory, the server has to publish the resource
  • A server has to be connected, authenticated and authorized to be able to publish / unpublish resources
  • During the lookup a client will retrieve only the resources it has access to
  • A client can perform CRUDN operations on resources which it has access to
  • A server has to be online to receive a CRUDN request
  • A client has to be informed that a request was successful or failed


An Aggregate is a resource hosted by a server. Concurrent requests to one server are not an issue and do not raise concurrency conflicts, until the same resource is requested concurrently. Most concurrency conflicts can be solved without informing the user, by applying optimistic locking with aggregate versioning.

Implementation details

CQRS Command Validation

Authorization is the business invariant, which has to be validated within each issued command to the Resource Aggregate.


  • OCF Server / Client are OCF actors communicating over CoAP through the OCF CoAP Gateway.
  • OCF CoAP Gateway is the component which takes care of translation of CoAP requests to commands accepted by an OCF Native Cloud reference implementation.
  • Resource Directory is the read model containing resource descriptions and up-to-date representations, built with events from the aggregate.

<WRAP center round info 90%> The component that implements the IRepository is responsible for persisting the aggregate and publishing any events raised by the aggregate on the event bus, all as part of a transaction. (e.g. event store) </WRAP>


OCF Servers and Clients communicate over CoAP and support CRUDN.

The OCF Native Cloud observes the published resources of OCF Servers and tracks all changes to these resources. A representation of the current state of resources is maintained in the form of a Resource Shadow. The OCF Native Cloud does not act as a gateway between device and client, and does not handle CoAP requests directly. Instead, the OCF CoAP Gateway handles these requests and transforms them into commands accepted by the Resource Bounded Context.

OCF Clients and Servers are able to invoke CRUDN operations on the OCF Native Cloud through the OCF CoAP Gateway, but the way these CoAP commands are handled differs.

    • Transformed to the Command CreateResource accepted by Resource Command Handler
    • Transformed to the Query accepted by the Resource Shadow / Resource Directory view models
    • Transformed to the Command UpdateResource accepted by Resource Command Handler
    • Transformed to the Command DeleteResource accepted by Resource Command Handler
    • Transformed to the Subscribe to the specific topic in the Event Bus, which contains ResourceRepresentationUpdated Events

<WRAP center round info 90%> Retrieval of a resource representation is not querying the device directly, as the OCF Native Cloud contains an up-to-date Resource Shadow based on ResourceRepresentationUpdated events. </WRAP>

Resource Directory

A frequently cited advantage of the CQRS pattern is that it enables you to scale the read side and write side of the application independently to support the different usage patterns. The Resource Aggregate, write side of the Resource Bounded Context is emitting events which are used for the building of the Resource Directory view model. The Resource Directory is therefore queried directly and can be scaled independent of the write side.

<WRAP center round important 90%> As the Resource Directory is built from Resource Aggregate events, it is not immediately consistent, but will be in time. </WRAP>

<WRAP center round info 90%> This approach also allows OCF Native Cloud users to build their own view model based on the Resource Aggregate events (e.g. flat resource structure where a root element is a device), which might make more sense for their domain. </WRAP>


The Command Handler for the Resource Directory Aggregate has the business invariant Authorization - which has to be validated within each issued command to the Resource Aggregate. Resource Directory, the read side has to return only those resources a user is authorized to receive. As each client / server is identified by the token, this token has to be used in the communication with the read side - Resource Directory.

Resource Shadow

Within the OCF Native Cloud, the resource shadow provides the latest representation of resources, because it is in sync with the physical devices. Through the use of the CQRS pattern, the resource shadow is the independently scaled, and the read side will eventually be consistent with the devices represented. It is not immediately consistent, since it takes time for the Resource Aggregate events to be handled, which it is built from.

<WRAP center round important 90%> As the Resource Shadow is built from Resource Aggregate events, it is not immediately consistent, but will be in time. </WRAP>

<WRAP center round info 90%> This approach also allows OCF Native Cloud users to build their own view model based on the Resource Aggregate events, and enrich it appropriate to their own domain. </WRAP>


The Command Handler for the Resource Directory Aggregate has the business invariant Authorization, which has to be validated within each issued command to the Resource Aggregate.

The read side of the Resource Shadow will return only those resources a user is authorized to receive. As each client / server pair is identified by a token, this token has to be used in the communication with the read side of the Resource Shadow.

Authorization Bounded Context

The following list defines the key domain-related terms.

  • Client is a logical entity that accesses a Resource on a Server.
  • OAuth Server is a server providing a mechanism for standardized access delegation.
  • Onboarding process of authenticating and authorizing the Server / Client to communication with the OCF Native Cloud.
  • Permission is the action of granting someone their request.
  • Server is a Device with the role of providing resource state information and facilitating remote interaction with its resources.
  • Security Identifier (SID) is a unique value of variable length used to identify a trustee. Each account has a unique SID issued by an authority, such as a Windows domain controller, and is stored in a security database.
  • User / Device Management is the component holding information on who has access to what.
  • User is an authenticated entity, authorized to onboard devices.

Requirements for working with authorization

To be able to communicate through the OCF Native Cloud, an OCF Server / Client has to first sign-up and sign-in. The Sign-up (registration of the entity), to the OCF Native Cloud requires a unique, one-time-use authorization code which is issued by an OAuth Server for a logged-in OCF Native Cloud user and transferred to the device. (The way the code is set on the device is not part of the OCF Native Cloud). The OCF Native Cloud will ask the OAuth server to verify the issued authorization code, if it is still valid and not yet used. After successful validation, the OAuth server returns an access token for further communication between the onboarded device and the OCF Native Cloud.

<WRAP center round info 90%> An access token is personalized, as it was issued by the subject (OCF Native Cloud User) for the specific device. </WRAP>

User/Device Management Component communicating with the OAuth Server (might be one component) assigns the device to the user who started the onboarding process - asked for authorization code and returns sign-in data back to the device as a response to the sign-up.

<WRAP center round info 90%> The OCF Native Cloud user who onboarded the device becomes the owner of this device. </WRAP>

When the OCF Server / Client is signed-up, it can continue with the sign-in process. A successfully signed-in device might publish its resources and be requested (CRUDN) through the OCF Native Cloud without limitation. The OCF Native Cloud itself is responsible for authorization requests from different OCF Servers / Clients. OCF Servers / Clients can communicate with each other, if they have the same owner (onboarded by the same user).

<WRAP center round important 90%> This is a simple default scenario, which will usually be modified by the companies using OCF Native Cloud. Management of users and devices is completely business specific and has to be modeled on your own. </WRAP>

Each request to a resource is validated with the Authorization Bounded Context and provides information, which user has permission to which OCF Client / Servers identified by the id.

<WRAP center round info 90%> Each request session must be backed by an access token, so the OCF Native Cloud can authorize that request. In case of the OCF Servers / Clients, a TCP session must be backed by the access token and validated through the sign-up process. Each command issued by the OCF CoAP Gateway is then backed by the validated token. </WRAP>


  • Server / Client has to be signed-up and signed-in to successfully communicate with the OCF Native Cloud
  • The user who onboarded the Server / Client has to be able to make requests to them through the OCF Native Cloud with his token
  • Servers and Clients onboarded by the same user have to be able to communicate with each other through the OCF Native Cloud, using the token received after the sign-up

Implementation details

To be able to clearly identify if the OCF Native Cloud User or the OCF Server / Client onboarded by them is authorized to make a request to another OCF Server, a concrete claim from the token of the requester must be mapped with the requested server id in the component responsible for the User / Device Management.

Candidate for the sample business invariant validation is the claim SID, which would identify an OCF Native Cloud User. The User / Device Management component would then provide information, which server IDs can be accessed by this user, identified by SID. As the OAuth Server would be most often provided by you, custom claims can be introduced and used for mapping with server IDs. For example, each OCF Native Cloud User belongs to a certain tenant, identified by a unique id. If the granularity of having devices accessible by tenants is enough for you, you're free to model it in this way and specify which claim should be used for validation inside the Command Handler of the Resource Bounded Context.


  • The Account Server, in the way it is implemented in IoTivity v1.3.0 is forcing users to use a very specific data model for authorization. The proposed solution is instead driven by the user, not forcing them to map it to an existing model.
    • Current implementation in the IoTivity SDK provides OCAccountManager, through which you can control access management. This is very user specific and does not belong in the device SDK. The cloud should stay separate as well as the authorization model inside the cloud API. In the new design, this is completely up to the user and shouldn't be exposed to the device.

OCF CoAP Gateway

OCF Servers / Clients communicate over TCP / UDP using the CoAP application protocol. Communication within the OCF Native Cloud shouldn't be restricted to the CoAP protocol, implementation should allow the use of whatever protocol might be introduced in the future. That's why the gateway is the access point for CoAP over TCP, and further communication is OCF Native Cloud specific.

TCP connection to the OCF Native Cloud is by its nature stateful. The OCF CoAP Gateway is therefore also stateful, keeping open connections to the OCF Servers / Clients. The goal of the Gateway is to translate between the OCF Servers / Clients (CoAP) and the protocol of the OCF Native Cloud and communicate in an asynchronous way.


  • OCF CoAP Gateway can accept requests from the OCF Client / Server only after a successful sign-in
  • OCF CoAP Gateway can forward requests to the OCF Client / Server only after successful sign-in
  • If sign-in was not issued within the configured amount of time or sign-in request failed, OCF Native Cloud will forcibly close the TCP connection
  • OCF CoAP Gateway sends command to update device core resource with its status.
    • Online when the device was successfully signed-in and communication lock released
    • Offline when the device was disconnected or signed-out
  • Access Token from a successful sign-in must be locally persisted in the OCF CoAP Gateway and linked with an opened TCP channel
  • Access Token linked with the opened TCP channel has to be included in each command issued to other OCF Native Cloud components
  • OCF CoAP Gateway processes only those commands, which are designated for a device which the Gateway has an opened TCP channel to
  • OCF CoAP Gateway is observing each resource published to the resource directory and publishes an event for every change
  • OCF CoAP Gateway retrieves each published resource and updates Resources
  • OCF CoAP Gateway has to expose the coap ping-pong + retry count configuration, which can be configured during the deployment
  • OCF CoAP Gateway has to ping the device in the configured time, if pong is not received after the configured number of retries, then the connection with the device is closed and device is set as offline
  • OCF CoAP Gateway processes events from Resources, by issuing a proper CoAP request to the device and raising an event with the response
  • OCF CoAP Gateway has to process a waiting request within the configured time, or set the device as offline

Load balancing

In case of a deployment with many OCF Clients / Servers, a single instance of the OCF CoAP Gateway is not enough. Scaling and load balancing of connections is required. More options are available:

  • Proxy
    • L3/4 (transport layer)
    • L7 (application layer)
  • Client side
    • Thick Client
    • Lookaside

As load balancing can be very user specific (e.g. OCF CoAP Gateway per tenant), OCF Native Cloud will not include this functionality. Users may already have a preferred solution in their infrastructure to handle load balancing or their needs may be excessively complicated (high performance, low lantency, many clients, etc.). That is why this topic is out of scope and will not be solved by OCF Native Cloud.

Implementation details


  • OCF Server / Client are OCF actors communicating over CoAP through the OCF CoAP Gateway.
  • OCF CoAP Gateway is the component which handles translation of CoAP requests to commands accepted by an OCF Native Cloud reference implementation.
  • Resources is the bounded context
  • Authorization is the bounded context


  • In the current design, the OCF CoAP Gateway also acts as a process manager. This might change in the future, mainly when a different gateway protocol is required. Due to the fact that:
    • We want to re-use the stateless nature of the OCF CoAP Gateway component
    • Validate the design and need for change during implementation

Sample Usage

The market is missing a remote system allowing OCF enabled devices to be connected so a device owner can see their state and control them. There are multiple use-cases for such a system (e.g. smart home, processing plants, hospitals, universities). Companies developing such systems want to support as many devices as possible without need for protocol adapters and device specific implementation, which might be provided by the OCF standard in the future. OCF Native Cloud should be open enough to allow companies who want to introduce such a system to do it without limitations, not forcing them to use specific technologies, but leave it up to them as much as possible. Integration with their existing system will become easier, resulting in a growth of users and increasing the number OCF enabled devices.

A company integrating the OCF Native Cloud based on the new design is not forced to use CoAP for communication with the OCF Native Cloud. OCF Devices are currently communicating with the OCF Native Cloud over CoAP, but that's a limitation to be overcome. To build a business case with OCF enabled devices and Native Cloud, user services have to be introduced and should be able to communicate with the OCF Native Cloud. As mentioned before, with no need for the use of CoAP. Services within the same deployment should effectively communicate in the same way the OCF CoAP Gateway is communicating with the rest of the system - Resource and Authorization bounded contexts.

Let's assume a company is already providing simple device management for their devices, but would also like to support an OCF enabled system which will guarantee more customers for their software. Their Device Management (DM) service exposes a REST API and allows users to configure them and see current readings of sensors attached to those devices. The company already has an OAuth based authorization server and User Management. What would the integration look like?

Integration details

  • Authorization bounded context of the OCF Native Cloud is their OAuth Server and User Management
    • Command Handler for commands coming from the OCF Native Cloud have to be implemented for their service
  • Device Management contains a view of their devices
    • Device Management has to query the Resource Directory / Resource Shadow when the DM user requests device information
  • User making requests through their REST API uses bearer token issued by their Authorization Server
    • This token has to be forwarded in the query to the Resource Directory / Resource Shadow to authorize the request

coapnativecloud.txt · Last modified: 2018/08/09 08:28 by ondrej.tomcik