Skip to content

What are Notifications in oneM2M?

Notifications are used to asynchronously inform enitities about changes in a oneM2M system.

oneM2M defines various operations to interact with the oneM2M resources. One of them is the notification operation. A notification is a request that is sent by a CSE to a registered application or another CSE when a resource changes, is added, or removed, or when a specific event occurs.

Subscribing to Notifications

In general, requests are sent by a client to a CSE, and the CSE processes the request and then sends a response back to the client. In contrast, notifications are sent by the CSE to a registered application or another CSE without a prior request from the receiver.

To receive notifications on resource updates, an application must subscribe to the events it is interested in. The <subscription> resource type specifies the resources that define the conditions under which notifications are sent.

sequenceDiagram
    participant AE
    participant CSE
    participant AE2 as Another AE

    rect
        note over AE, CSE: Subscribe to Updates
        AE ->> CSE: Create <subscription><br/>for aResource
        CSE -->> AE: Response
    end


    rect
    note over AE, AE2: Some time later
        AE2 ->> CSE: Update aResource
        CSE -->> AE2: Response
        CSE ->> AE: Notification
        AE -->> CSE: Response
        AE ->> AE: Handle Notification
    end
Figure 1: Subscription and Notification Sequence

Figure 1 shows the sequence of a subscription for updates on a resource and the subsequent notification when the resource is updated. The sequence starts with an application (AE) subscribing to updates on a resource by creating a <subscription> resource. When the resource is updated, for example by another AE, the CSE sends a notification to the subscriber.

The <subscription> resource specifies the conditions under which notifications are sent. But the configuration can be more complex than just specifying the resource and the condition to monitor. For example, it may include the format of the notification, the resource types and attributes to monitor, handling for rate limits and batch notifictions, and more.

Point-of-Access

A subscription may contain either a direct URL for the notification target or references to <AE> resources that have a point-of-access to the CSE.

In order to receive notifications directly, an application mus have a point-of-access to the CSE. This is usually done by setting the pointofAccess (poa) attribute of the <AE> resource to one or more addresses where it can receive notifications from the CSE. The protocol used for notification delivery can be any protocol supported by the CSE, such as HTTP, CoAP, WebSocket, or MQTT.

Reachability

It may be the case that an application is not able to host a server that can receive notifications,for example because it is behind a firewall or NAT, or the device is not always online or just too limited in resources.

In this case, the application can set its requestReachability (rr) attribute to false and the CSE will not try to send notifications to the application directly. Instead, the application must poll the CSE for notifications. The CSE will store the notifications until the application retrieves them.

This is done by creating a <pollingChannel> resource under the <AE> resource. By polling this resource, the application can retrieve any outstanding notification on its own schedule.

Example

See How to Subscribe to Notifications for a detailed example on how to subscribe to notifications.

by Andreas Kraft, 2024-04-05