Skip to content

Registering a CSE to another CSE

oneM2M supports the registration of one CSE to another one. Interconnected CSEs form a tree-like network where resources are announced and requests can be sent across the deployed CSEs, and which can be used to hierarchical manage IoT devices and applications.

This article gives an overview of the registration process to connect CSEs.

CSE Deployment Tree Example

Figure 1: CSE Deployment Tree Example

In the example deployment tree in Figure 1 the MN-CSE-1-1 is registered to the MN-CSE-1, and the MN-CSE-2-1 is registered to the MN-CSE-2. Both MN-CSE-1 and MN-CSE-2 are registered to the IN-CSE.

Registree and Registrar

The CSE that wants to register to another CSE is called the registree. The CSE that accepts the registration is called the registrar. A CSE can only be registered to one registrar CSE, while a registrar CSE can accept registrations from multiple registree CSEs.

For example, in Figure 1 the MN-CSE-1-1 is the registree and the MN-CSE-1 is the registrar. Also, both MN-CSE-1 and MN-CSE-2 are registrees to the registrar IN-CSE.

The following table shows the possible roles that the different CSE types can take in the registration process:

CSE Type Registree Registrar
IN-CSE No Yes
MN-CSE Yes Yes
ASN-CSE Yes No
Table 1: CSE Types and Registration Roles

The Registration Process

The registration process is always initiated by a registree CSE that wants to register to a registrar CSE. The registration is a three-step process:

  • The first step is to send a registration request to the target CSE. This is done by creating a new <remoteCSE> resource in the registrar CSE. This resource contains the necessary information for the registrar CSE to contact the registree CSE, such as the protocol and host address, the serialization format and the supported oneM2M release version(s). 1

  • After the successful creation of the <remoteCSE> resource on the registrar CSE the registree CSE retrieves the registrar CSE's <CSEBase> resource and then creates a counterpart <remoteCSE> resource on its own resource tree that contains the necessary information for the registree CSE to send further requests to the registrar CSE. 2

  • If the registrar itself is a registree to another CSE, the registration information is forwarded to that next higher CSE. This is done by the registrar CSE by updating the descendantCSEs attribute in its <remoteCSE> resource of its registrar CSE.

The descendantCSEs Attribute

The descendantCSEs attribute in the <remoteCSE> resource is used to keep track of all the registered CSEs "beneath" a CSE. It is a list of all the CSE-IDs of the CSEs that are located under its sub-tree.

It is the responsibility of a registrar CSE to keep this list up-to-date and to update its registrar CSE about changes in the list.

The sequence diagram in Figure 2 shows the registration steps:

Registration Sequence

Figure 2: Registration Sequence

Updating a Registration

Updating a registration to another CSE is needed when a registree CSE is registering to or de-registering from a registrar CSE, and this registrar CSE must inform its own registrar CSE about the change by updating the descendantCSEs attribute in the <remoteCSE> resource.

The process is similar a normal update of a resource, where the <remoteCSE> resource is updated with the new information. Figure 3 shows the sequence diagram for updating a registration.

The sequence diagram in Figure 3 shows the update steps:

Updating a Registration Sequence

Figure 3: Updating a Registration Sequence

De-registering a CSE

De-registering a CSE from another CSE is done in two steps:

  • In the first step the registree CSE deletes its <remoteCSE> resource on the registrar CSE. The registrar CSE will also inform its own registrar CSE about the change by updating the descendantCSEs attribute accordingly.
    This will remove the registree CSE and all its descendant CSEs from the CSE deployment tree. For example, if the MN-CSE-1 in Figure 1 de-registers from the IN-CSE, the MN-CSE-1-1 will also become unreachable from the IN-CSE, even if it is still registered to MN-CSE-1.
  • In the second step the registree CSE deletes the local counterpart of the registrar's <remoteCSE> resource.

This will trigger the registrar CSE to update its descendantCSEs attribute and to inform its own registrar CSE about the change.

The sequence diagram in Figure 4 shows the de-registration steps:

Updating a Registration Sequence

Figure 4: De-Registration Sequence

Summary

This article gave an overview of the registration process to connect CSEs in a hierarchical network. Registration and de-registration is initiated by a registree CSE that wants to register to a registrar CSE.

by Andreas Kraft, 2024-03-30

  1. The necessary information and security assets to contact the registrar CSE need to be pre-provisioned, for example in a configuration file or by using a (non-oneM2M) discovery mechanism. ↩

  2. It is up to each CSE to regularly check the status and reachability of remote CSEs, and to remove registrations if they are no longer valid. ↩