]> IMT Atlantique

laurent.toutain@imt-atlantique.fr

IRTF Thing-to-Thing Research Group (T2TRG) CORECONF CoMI YANG CBOR CoAP M2M IoT constrained devices SID The document addresses the specific challenges of M2M interactions where both endpoints may be constrained nodes, and explores the use of CORECONF primitives. This document describes the use of CORECONF (CoAP Management Interface) for Machine-to-Machine (M2M) communication in constrained IoT environments. It defines a YANG data model enabling remote management and configuration of constrained devices using CoAP, CBOR, and YANG SID identifiers. The serialization in CBOR of this data model limits the payload size.

This document proposes a YANG data model designed for constrained devices and low-power networks. By combining YANG’s strong typing with CBOR’s compact binary serialization and CoAP’s lightweight transport, the model enables efficient Machine-to-Machine (M2M) data exchange while remaining within the bandwidth and energy budgets of constrained environments. SCHC header compression may further be used to reduce the overhead of IPv6, UDP, and CoAP headers on the most constrained links. Some data models and protocols already exist for M2M communication in IoT environments, but none is fully adapted to the constraints of low-power networks in terms of message size, energy consumption, and interaction patterns. This section reviews the main existing approaches and explains why a new model is needed. SenML has become a widely adopted format for Machine-to-Machine (M2M) data exchange in IoT environments, enabling constrained devices to report sensor measurements and time series in JSON or CBOR. However, SenML is primarily a data serialization format: it structures payloads but does not enforce strong type checking, schema validation, or support for configuration and remote operations. SenML is also part of the LwM2M framework , which defines a broader device management protocol built on CoAP and SenML for operator-to-device interactions. However, LwM2M relies on periodic reporting and registration messages that impose a non-trivial overhead, particularly on Low-Power Wide-Area Networks (LPWANs) where bandwidth and energy budgets are severely constrained. In some ways, SenML may be described by a YANG Data Model , but the integration in the YANG ecosystem remains limited. The CORECONF protocol stack using YANG for Data Modeling, CoAP for data transport, and CBOR and YANG SID identifiers for the compact data serialization provides the richer foundation that SenML lacks: a strongly typed data model, schema validation, and support for full CRUD operations and actions. However, CORECONF has so far been designed for operator-to-device management, leaving peer-to-peer M2M communication — where both endpoints may themselves be constrained nodes — largely unaddressed. Some YANG Data Models have been defined for telemetry. introduces Network Telemetry used to collect vast amounts of data to supervise a network. allows subscribing to a datastore filtered through XPath and receiving notifications. proposes to extend telemetry to CORECONF, but using a traditional approach. This document adopts a different approach. The goal is to define a YANG Data Model that will benefit from CBOR serialization to optimize the bandwidth to extend CORECONF for M2M use cases over low-power links. This document focuses on transducer management: resource discovery, value polling, statistical computation, threshold alerts, and time-series history notifications. This is an early-stage work; future revisions will explore other categories of measurements and interaction patterns.

The targeted use cases are remote sensors installed in the field and connected with LPWAN or Satellite connectivity. SCHC is used to compress headers such as IPv6, UDP and CoAP for CORECONF traffic. The payload results from the serialization of the datastore in CBOR. The model covers the following use cases: resource discovery: sensors or actuators, regrouped under the name transducers, are discovered with their characteristics (units, precision) simple query: each transducer can be individually queried or set. statistical computation: the sensor can compute some statistical values, such as mean, variance, min and max. They can be reset. alert notification: when a value reaches a threshold (minimum and maximum) a notification message is sent time series: values are collected by the device and sent when a limit is reached (number of samples, duration, message size)

CBOR is designed to be concise to represent numerical information since it is directly coded in binary and not represented in ASCII. CBOR also uses binary representation to encode structures such as Maps and Arrays. The length of a numerical value depends on its value; for instance, numbers between -24 and 23 are coded on a single byte, values between -255 and 255 on two bytes,… Nevertheless, some representations may be less efficient numerically or less precise. CBOR defines 3 IEEE 754 encodings on 3, 5, or 9 bytes. The smallest representation introduces a close to 1% error. CBOR also provides a decimal fraction type (tag 4) encoding a value as a [exponent, mantissa] pair, which avoids floating-point rounding. However, this representation requires the exponent (the divider) to be repeated alongside every individual quantity, adding overhead for each encoded value. The assumption leading to this YANG module is to avoid floating-point numbers for their size or precision and rely on integers with a precision parameter indicating, if positive, the number of digits after the decimal point, or the power of 10 if negative. The module also introduces the notion of time series to record several measurements during a period of time and send them in a single message using a notification. Time series values may further be compressed depending on the nature of the data. This version proposes a compression based on delta encoding: instead of transmitting absolute values, each sample is encoded as the difference from the previous one, which significantly reduces the CBOR payload size for slowly-varying measurements. The device can also send an alert when a measured value reaches a threshold, allowing the receiver to react promptly without waiting for a scheduled report.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

The following terminology is used in this document: CoAP Management Interface, as defined in . Machine-to-Machine communication, referring to direct data exchanges between devices without human intervention. YANG Schema Item iDentifier, a compact numeric identifier for YANG data nodes, as defined in . A device with limited processing, memory, and energy resources, as characterized in . A piece of equipment containing one or more transducers. an interface between the analog and digital world. Transducers are sensors reporting values or actuators having an action on the physical world. values manipulated by transducers. other information stored in the datastore including quantities

The device acts as a CoAP server implementing CORECONF and exposes its state through a set of Transducers. A Transducer represents either a sensor (providing measurements) or an actuator (accepting commands). Each Transducer type is identified by a YANG identity. When multiple Transducers of the same type are present on the device, they are distinguished by an instance identifier.

For simplicity reasons, we regroup in a single YANG module two elements. The first element is a set of Transducer identities, which in a real deployment would typically reside in a separate device-specific module. In this example, 12 transducers are defined, corresponding to the weather station ATMOS41 (see https://metergroup.com/fr/products/atmos-41/). The second element defines the data structures: a container including a device description and a list of associated transducers. Each transducer is identified by an identityref and an instance number, allowing several transducers of the same type. Each transducer contains: a quantity measured from the field or set by the client. a list of statistics (mean, variance, min, max), resettable via RPC. alert parameters: threshold values (minimum and maximum) triggering a notification when the measured quantity crosses them. time series parameters: collection settings controlling when a series of samples is sent (number of samples, duration, message size). an RPC, now limited to resetting all statistics two notification types: one to collect time-series history, and one to alert when a quantity reaches a minimum or maximum threshold. gives an overview of the module YANG tree:

These two sub-trees contain global parameters generic to the device, such as uptime. They are still under development and their content is not yet fully defined.

Transducers sub-tree contains the list of transducers (i.e. sensors, actuators) maintained by the device. A transducer is identified by two elements: a “type” identityref giving the nature of the transducer, an “id” giving the instance number allowing several transducers of the same type. At this level, three other leaves are defined: “unit” is a string giving the nature of the quantity. This value may be taken from SenML maintained by IANA. The use of a string, instead of identityref is intentional. Units are short names. YANG Identity may be larger and less flexible. “nature” reveals if a transducer is a sensor, from which the quantity can be read, or an actuator where the quantity can be written. “precision”: is the number of digits after the decimal point. Quantity values are integers multiplied by 10^precision. It can be noted that precision can also be negative for very large values. These five leaves form the first level of the transducers tree. The recommended approach is to query with depth=0, which returns only the transducer list with its identifying leaves (type, id, unit, nature, precision). This lightweight exchange is sufficient for resource discovery and minimizes traffic on constrained networks. A query with depth=1 is also possible and returns transducers together with their associated quantity values in a single message. However, the response may be significantly larger, as it includes timestamp and statistics data that the client may not need. On low-power links, it is therefore preferable to perform discovery and value retrieval as two separate queries.

The “quantity” sub-tree pushes the leaves to a deeper level, to avoid being retrieved during the resource discovery phase. Quantity contains: the value adjusted with the precision to be an integer, the timestamp in seconds and microseconds, the entity in charge of the timestamp, which can be the device itself or the receiver. Under “quantity”, the sub-level “statistics” includes major statistic for a specific transducer. Locally computed statistics. Statistics may be erased for each transducer by calling the “reset-stats” action, or globally for all transducers with the “reset-stats” RPC.

The model supports two kinds of notifications: “sensor-alert” will send a notification when the measured quantity reaches one or two limits, minimal and maximal, or goes back to a value between these two bounds. To avoid fluctuations, two mechanisms are in place: “hysteresis” defines a percentage, by default 5% around the limit, so if a maximum limit is set to 100, an alert message will be triggered when the quantity is higher than 105 and another alert will be sent when the quantity becomes lower than 95%. The value is sent in the notification message, so the client is able to know the state of the alert. “dampening” limits the number of messages sent. “history” builds time series: “step” parameter defines at which interval samples are taken. “precision” allows overriding the quantity precision defined in the transducer. By default the precision is the one associated with the transducer. “encoding” indicates how information is stored in the time series: “direct”: all the values are stored with the precision. “delta”: the first value is the reference and the following ones are the difference with the previous. This allows limiting the size of the message since CBOR encodes small numbers more efficiently. A notification is sent when a number of measurements is reached, either: the number of samples in the time series reaches “max-samples”, “max-payload” is based on the size of the time series. Since small numbers take less space than large numbers in CBOR, a time series may contain a different number of samples. the “time-period” after which the collection should be sent. The read-only active flag in both notification types is set when one or more clients observe a notification. Parameters are common to all observations of a particular transducer.

A client wishing to initiate a notification MAY first send an iPATCH to set up notification parameters. Parameters set during an active notification are immedialty applied. Notification is started by sending a FETCH+Observe request on the notification stream resource (/s), with a body identifying the SID of the transducer to observe. Multiple clients may observe the same transducer simultaneously; each receives an independent copy of every notification.

CORECONF defines mappings for all CoAP methods, but this document uses only two: FETCH is used instead of GET to retrieve values from the YANG Data Model. Unlike GET, FETCH carries a body specifying the exact SIDs to retrieve, enabling precise and bandwidth-efficient queries. Combined with the CoAP Observe option, FETCH also serves to subscribe to notification streams. iPATCH is used instead of PUT or POST to modify quantities and notification parameters. It supports partial updates: only the specified nodes are modified, leaving others unchanged. Setting a node to an empty value with iPATCH is the preferred way to clear a parameter, making DELETE unnecessary for datastore modifications. The recommended CoAP Content-Formats for all exchanges are: Content-Format 141 (application/yang-fetch+cbor) for FETCH request bodies, which carry the list of SIDs to retrieve. Content-Format 142 (application/yang-data+cbor;id=sid) for all response bodies and iPATCH payloads, where data nodes are identified by their SID. Using these two content formats ensures maximum interoperability with CORECONF implementations and keeps the payloads as compact as possible. Limiting exchanges to a small number of well-known packet formats also benefits SCHC compression : the fewer distinct header patterns in use, the more efficiently SCHC rules can compress the CoAP headers, reducing overhead on the most constrained links. FETCH and iPATCH requests MUST be sent as Non-Confirmable (NON) CoAP messages. This leaves the application free to implement its own retransmission strategy and timer management, which is essential on constrained networks where the default CoAP confirmable retransmission behavior may be inappropriate or wasteful. For notification streams (Observe), Confirmable (CON) messages MAY be used. A CON notification allows the server to detect that the observer is no longer reachable when no ACK is received, and to cancel the Observe subscription accordingly. A RST response from the client is also a valid way to signal that the subscription should be terminated.

The following examples show some CoAP messages between a client and a device (the CoAP server). In the example, the device is an ATMOS41 weather station, able to measure 12 parameters. An identity is associated with each parameter and a unique SID, as illustrated in :

The client does not know the transducers managed by the device. It sends a FETCH on “/transducers/transducer” with a depth of 0, as shown in .

In the request, the payload 1A 000186DF is the CBOR encoding of the unsigned integer 100063, which is the SID of “/transducers/transducer”. In the response, the outer key 100063 identifies the list, and each entry is a CBOR map whose keys are delta SIDs relative to the list SID, as defined in . The values encode the transducer type (as an identity SID), instance id, precision, and unit string. The client may translate the identityref values to the names defined in the YANG module. shows the resulting transducer table:

A specific quantity may be requested through a FETCH. shows the exchange for the current value of air-temperature.

The FETCH body [100092, 100001, 0] is a CORECONF instance-identifier: the first element is the SID of the requested leaf, followed by the list key values identifying the transducer (type=100001 for air-temperature, id=0). The response value 112, combined with precision=1, decodes to 11.2°C. shows the FETCH for the full statistics table of the same transducer:

The FETCH body [100082, 100001, 0] requests the quantity sub-tree (SID 100082) for air-temperature (100001), instance 0. In the response, the inner map keys are delta SIDs relative to 100082, each encoding the difference between consecutive SIDs to minimize CBOR size. The six values correspond to the statistics leaves: min, max, mean, median, stdev, and sample-count, all scaled by the transducer precision. The client decodes the response and displays the statistics as shown in :

The client first sends an iPATCH to configure the history notification parameters for the solar-radiation transducer, as shown in .

The iPATCH key [100066, 100008, 0] is an instance-identifier targeting the notification-parameters node (SID 100066) for solar-radiation (SID 100008), instance 0. The value {100066: {6: 5000, 4: 3, 2: 1}} sets three history parameters using delta SIDs relative to 100066: step=5000 ms (one sample every 5 seconds), max-samples=3, and encoding=delta (value 1). The client then initiates an Observe subscription with a FETCH on the notification stream resource /s, as shown in .

The FETCH body [100044, 100008, 0] subscribes to the history time-series stream (SID 100044) for solar-radiation. The server acknowledges with an empty map {}. In the notification, the outer key 100042 identifies the history notification; the inner structure uses delta SIDs to encode type, id, and the values list. The values [1043, 82, 82, ...] use delta encoding: 1043 is the absolute reference (104.3 W/m²), and each subsequent value is the difference from the previous one, yielding a compact representation of slowly-varying measurements. The client decodes the delta-encoded time-series values and displays the result as shown in :

The SID range 100000–100399 is used as an example throughout this document. Official values MUST be assigned by IANA prior to publication. The complete SID file is provided in .

CORECONF operations over CoAP MUST be secured using either DTLS or OSCORE . In M2M scenarios where a central manager is absent, the trust model requires particular attention.

This document registers the following YANG module in the “YANG Module Names” registry : Name Namespace Prefix Reference coreconf-m2m urn:ietf:params:xml:ns:yang:coreconf-m2m cm2m This document

This document requests the SID range starting at entry-point TBD with a size of 100, as defined in . Transducer identites MUST be sperated from this document and defined in anjother YANG module.

&RFC7252; &RFC7950; &RFC8610; &RFC8724; &RFC8824; &RFC9254; &RFC9363; &I-D.ietf-core-comi; &RFC2119; &RFC8174; &RFC8376; &RFC9179; &RFC8949; &RFC7396; &RFC8428; &RFC9232; &RFC8639; &I-D.ietf-core-sid; &I-D.ietf-core-yang-cbor; &I-D.gudi-t2trg-senml-as-coreconf; &I-D.birkholz-yang-core-telemetry; &RFC7228; &RFC6347; &RFC8613;

The following table lists the SID assignments for the coreconf-m2m module (assignment range: 100000–100399, revision 2026-03-29).

This work has been supported by the SCHC Chair from IMT Atlantique and Afnic.