Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8428

Sensor Measurement Lists (SenML)

Pages: 54
Proposed Standard
Errata
Updated by:  9100
Part 1 of 3 – Pages 1 to 19
None   None   Next

Top   ToC   RFC8428 - Page 1
Internet Engineering Task Force (IETF)                       C. Jennings
Request for Comments: 8428                                         Cisco
Category: Standards Track                                      Z. Shelby
ISSN: 2070-1721                                                      ARM
                                                                J. Arkko
                                                              A. Keranen
                                                                Ericsson
                                                              C. Bormann
                                                 Universitaet Bremen TZI
                                                             August 2018


                    Sensor Measurement Lists (SenML)

Abstract

This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8428.
Top   ToC   RFC8428 - Page 2
Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. SenML Structure and Semantics . . . . . . . . . . . . . . . . 6 4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Regular Fields . . . . . . . . . . . . . . . . . . . . . 7 4.3. SenML Labels . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Records and Their Fields . . . . . . . . . . . . . . . . 9 4.5.1. Names . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5.2. Units . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.3. Time . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.4. Values . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Resolved Records . . . . . . . . . . . . . . . . . . . . 12 4.7. Associating Metadata . . . . . . . . . . . . . . . . . . 12 4.8. Sensor Streaming Measurement Lists (SenSML) . . . . . . . 12 4.9. Configuration and Actuation Usage . . . . . . . . . . . . 13 5. JSON Representation (application/senml+json) . . . . . . . . 13 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Single Data Point . . . . . . . . . . . . . . . . . . 14 5.1.2. Multiple Data Points . . . . . . . . . . . . . . . . 14 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 15 5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 17 5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 17 5.1.6. Collection of Resources . . . . . . . . . . . . . . . 18 5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 18 6. CBOR Representation (application/senml+cbor) . . . . . . . . 19 7. XML Representation (application/senml+xml) . . . . . . . . . 21 8. EXI Representation (application/senml-exi) . . . . . . . . . 23
Top   ToC   RFC8428 - Page 3
   9.  Fragment Identification Methods . . . . . . . . . . . . . . .  26
     9.1.  Fragment Identification Examples  . . . . . . . . . . . .  26
     9.2.  Fragment Identification for XML and EXI Formats . . . . .  27
   10. Usage Considerations  . . . . . . . . . . . . . . . . . . . .  27
   11. CDDL  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  29
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
     12.1.  SenML Units Registry . . . . . . . . . . . . . . . . . .  30
     12.2.  SenML Labels Registry  . . . . . . . . . . . . . . . . .  35
     12.3.  Media Type Registrations . . . . . . . . . . . . . . . .  36
       12.3.1.  senml+json Media Type Registration . . . . . . . . .  37
       12.3.2.  sensml+json Media Type Registration  . . . . . . . .  38
       12.3.3.  senml+cbor Media Type Registration . . . . . . . . .  39
       12.3.4.  sensml+cbor Media Type Registration  . . . . . . . .  41
       12.3.5.  senml+xml Media Type Registration  . . . . . . . . .  42
       12.3.6.  sensml+xml Media Type Registration . . . . . . . . .  43
       12.3.7.  senml-exi Media Type Registration  . . . . . . . . .  44
       12.3.8.  sensml-exi Media Type Registration . . . . . . . . .  45
     12.4.  XML Namespace Registration . . . . . . . . . . . . . . .  47
     12.5.  CoAP Content-Format Registration . . . . . . . . . . . .  47
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  47
   14. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  48
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  49
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  49
     15.2.  Informative References . . . . . . . . . . . . . . . . .  51
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  53
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  54

1. Overview

Connecting sensors to the Internet is not new, and there have been many protocols designed to facilitate it. This specification defines a format and media types for carrying simple sensor information in protocols such as HTTP [RFC7230] or CoAP [RFC7252]. The SenML format is designed so that processors with very limited capabilities could easily encode a sensor measurement into the media type, while at the same time, a server parsing the data could collect a large number of sensor measurements in a relatively efficient manner. SenML can be used for a variety of data flow models, most notably data feeds pushed from a sensor to a collector, and for the web resource model where the sensor data is requested as a resource representation (e.g., "GET /sensor/temperature"). There are many types of more complex measurements and measurements that this media type would not be suitable for. SenML strikes a balance between having some information about the sensor carried with the sensor data so that the data is self-describing, but it also tries to make that a fairly minimal set of auxiliary information for
Top   ToC   RFC8428 - Page 4
   efficiency reasons.  Other information about the sensor can be
   discovered by other methods such as using the Constrained RESTful
   Environments (CoRE) Link Format [RFC6690].

   SenML is defined by a data model for measurements and simple metadata
   about measurements and devices.  The data is structured as a single
   array that contains a series of SenML Records that can each contain
   fields such as a unique identifier for the sensor, the time the
   measurement was made, the unit the measurement is in, and the current
   value of the sensor.  Serializations for this data model are defined
   for JSON [RFC8259], CBOR [RFC7049], XML [W3C.REC-xml-20081126], and
   Efficient XML Interchange (EXI) [W3C.REC-exi-20140211].

   For example, the following shows a measurement from a temperature
   gauge encoded in the JSON syntax.

   [
     {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
   ]

   In the example above, the array has a single SenML Record with a
   measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a
   current value of 23.1 degrees Celsius.

2. Requirements and Design Goals

The design goal is to be able to send simple sensor measurements in small packets from large numbers of constrained devices. Keeping the total size of the payload small makes it easy to also use SenML in constrained networks, e.g., in an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) [RFC4944]. It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on an 8-bit microprocessor. Experience with power meters and other large-scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request. This "batch" upload capability allows the server side to efficiently support a large number of devices. It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time. The multiple measurements could be from multiple related sensors or from the same sensor but at different times.
Top   ToC   RFC8428 - Page 5
   The basic design is an array with a series of measurements.  The
   following example shows two measurements made at different times.
   The value of a measurement is given by the "v" field, the time of a
   measurement is in the "t" field, the "n" field has a unique sensor
   name, and the unit of the measurement is carried in the "u" field.

   [
     {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,
      "v":23.5},
     {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020091e+09,
      "v":23.6}
   ]

   To keep the messages small, it does not make sense to repeat the "n"
   field in each SenML Record, so there is a concept of a Base Name,
   which is simply a string that is prepended to the Name field of all
   elements in that Record and any Records that follow it.  So, a more
   compact form of the example above is the following.

   [
     {"bn":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,
      "v":23.5},
     {"u":"Cel","t":1.276020091e+09,
      "v":23.6}
   ]

   In the above example, the Base Name is in the "bn" field, and the "n"
   fields in each Record are empty strings, so they are omitted.

   Some devices have accurate time while others do not, so SenML
   supports absolute and relative times.  Time is represented in
   floating point as seconds.  Values greater than or equal to 2**28
   represent an absolute time relative to the Unix epoch.  Values less
   than 2**28 represent time relative to the current time.

   A simple sensor with no absolute wall-clock time might take a
   measurement every second, batch up 60 of them, and then send the
   batch to a server.  It would include the relative time each
   measurement was made compared to the time the batch was sent in each
   SenML Record.  If the server has accurate time based on, e.g., the
   Network Time Protocol (NTP), it may use the time it received the data
   and the relative offset to replace the times in the SenML with
   absolute times before saving the SenML information in a document
   database.
Top   ToC   RFC8428 - Page 6

3. Terminology

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document also uses the following terms: SenML Record: One measurement or configuration instance in time presented using the SenML data model. SenML Pack: One or more SenML Records in an array structure. SenML Label: A short name used in SenML Records to denote different SenML fields (e.g., "v" for "value"). SenML Field: A component of a record that associates a value to a SenML Label for this record. SenSML: Sensor Streaming Measurement List (see Section 4.8). SenSML Stream: One or more SenML Records to be processed as a stream. This document uses the terms "attribute" and "tag" where they occur with the underlying technologies (XML, CBOR [RFC7049], and the CoRE Link Format [RFC6690]); they are not used for SenML concepts, per se. However, note that "attribute" has been widely used in the past as a synonym for the SenML "field". All comparisons of text strings are performed byte by byte, which results in the comparisons being case sensitive. Where arithmetic is used, this specification uses the familiar notation of the programming language C, except that the operator "**" stands for exponentiation.

4. SenML Structure and Semantics

Each SenML Pack carries a single array that represents a set of measurements and/or parameters. This array contains a series of SenML Records with several fields described below. There are two kinds of fields: base and regular. Both the base and regular fields can be included in any SenML Record. The base fields apply to the entries in the Record and also to all Records after it up to, but not
Top   ToC   RFC8428 - Page 7
   including, the next Record that has that same base field.  All base
   fields are optional.  Regular fields can be included in any SenML
   Record and apply only to that Record.

4.1. Base Fields

Base Name: This is a string that is prepended to the names found in the entries. Base Time: A base time that is added to the time found in an entry. Base Unit: A base unit that is assumed for all entries, unless otherwise indicated. If a record does not contain a Unit value, then the Base Unit is used. Otherwise, the value found in the Unit (if any) is used. Base Value: A base value is added to the value found in an entry, similar to Base Time. Base Sum: A base sum is added to the sum found in an entry, similar to Base Time. Base Version: Version number of the media type format. This field is an optional positive integer and defaults to 10 if not present.

4.2. Regular Fields

Name: Name of the sensor or parameter. When appended to the Base Name field, this must result in a globally unique identifier for the resource. The name is optional, if the Base Name is present. If the name is missing, the Base Name must uniquely identify the resource. This can be used to represent a large array of measurements from the same sensor without having to repeat its identifier on every measurement. Unit: Unit for a measurement value. Optional. Value: Value of the entry. Optional if a Sum value is present; otherwise, it's required. Values are represented using basic data types. This specification defines floating-point numbers ("v" field for "Value"), booleans ("vb" for "Boolean Value"), strings ("vs" for "String Value"), and binary data ("vd" for "Data Value"). Exactly one Value field MUST appear unless there is a Sum field, in which case it is allowed to have no Value field. Sum: Integrated sum of the values over time. Optional. This field is in the unit specified in the Unit value multiplied by seconds. For historical reasons, it is named "sum" instead of "integral".
Top   ToC   RFC8428 - Page 8
   Time:  Time when the value was recorded.  Optional.

   Update Time:  Period of time in seconds that represents the maximum
      time before this sensor will provide an updated reading for a
      measurement.  Optional.  This can be used to detect the failure of
      sensors or the communications path from the sensor.

4.3. SenML Labels

Table 1 provides an overview of all SenML fields defined by this document with their respective labels and data types. +---------------+-------+------------+------------+------------+ | Name | Label | CBOR Label | JSON Type | XML Type | +---------------+-------+------------+------------+------------+ | Base Name | bn | -2 | String | string | | Base Time | bt | -3 | Number | double | | Base Unit | bu | -4 | String | string | | Base Value | bv | -5 | Number | double | | Base Sum | bs | -6 | Number | double | | Base Version | bver | -1 | Number | int | | Name | n | 0 | String | string | | Unit | u | 1 | String | string | | Value | v | 2 | Number | double | | String Value | vs | 3 | String | string | | Boolean Value | vb | 4 | Boolean | boolean | | Data Value | vd | 8 | String (*) | string (*) | | Sum | s | 5 | Number | double | | Time | t | 6 | Number | double | | Update Time | ut | 7 | Number | double | +---------------+-------+------------+------------+------------+ Table 1: SenML Labels (*) Data Value is a base64-encoded string with the URL-safe alphabet as defined in Section 5 of [RFC4648], with padding omitted. (In CBOR, the octets in the Data Value are encoded using a definite- length byte string, major type 2.) For details of the JSON representation, see Section 5; for CBOR, see Section 6; and for XML, see Section 7.
Top   ToC   RFC8428 - Page 9

4.4. Extensibility

The SenML format can be extended with further custom fields. Both new base and regular fields are allowed. See Section 12.2 for details. Implementations MUST ignore fields they don't recognize unless that field has a label name that ends with the "_" character, in which case an error MUST be generated. All SenML Records in a Pack MUST have the same version number. This is typically done by adding a Base Version field to only the first Record in the Pack or by using the default value. Systems reading one of the objects MUST check for the Base Version field. If this value is a version number larger than the version that the system understands, the system MUST NOT use this object. This allows the version number to indicate that the object contains structure or semantics that is different from what is defined in the present document beyond just making use of the extension points provided here. New version numbers can only be defined in an RFC that updates this specification or its successors.

4.5. Records and Their Fields

4.5.1. Names

The Name value is concatenated to the Base Name value to yield the name of the sensor. The resulting concatenated name needs to uniquely identify and differentiate the sensor from all others. The concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", and "0" to "9", as well as "-", ":", ".", "/", and "_"; furthermore, it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9". This restricted character set was chosen so that concatenated names can be used directly within various URI schemes (including segments of an HTTP path with no special encoding; note that a name that contains "/" characters maps into multiple URI path segments) and can be used directly in many databases and analytic systems. [RFC5952] contains advice on encoding an IPv6 address in a name. See Section 14 for privacy considerations that apply to the use of long-term stable unique identifiers. Although it is RECOMMENDED that concatenated names be represented as URIs [RFC3986] or URNs [RFC8141], the restricted character set specified above puts strict limits on the URI schemes and URN namespaces that can be used. As a result, implementers need to take care in choosing the naming scheme for concatenated names, because such names both need to be unique and need to conform to the restricted character set. One approach is to include a bit string
Top   ToC   RFC8428 - Page 10
   that has guaranteed uniqueness (such as a 1-wire address [AN1796]).
   Some of the examples within this document use the device URN
   namespace as specified in [DEVICE-URN].  Universally Unique
   Identifiers (UUIDs) [RFC4122] are another way to generate a unique
   name.  However, the restricted character set does not allow the use
   of many URI schemes, such as the "tag" scheme [RFC4151] and the "ni"
   scheme [RFC6920], in names as such.  The use of URIs with characters
   incompatible with this set and possible mapping rules between the two
   are outside the scope of the present document.

4.5.2. Units

If the Record has no Unit, the Base Unit is used as the Unit. Having no Unit and no Base Unit is allowed; any information that may be required about units applicable to the value then needs to be provided by the application context.

4.5.3. Time

If either the Base Time or Time value is missing, the missing field is considered to have a value of zero. The Base Time and Time values are added together to get a value representing the time of measurement. Values less than 268,435,456 (2**28) represent time relative to the current time. That is, a time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now". A negative value indicates seconds in the past from roughly "now". Positive values up to 2**28 indicate seconds in the future from "now". An example for employing positive values would be actuation use, when the desired change should happen in the future, but the sender or the receiver does not have accurate time available. Values greater than or equal to 2**28 represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time), and the time is counted the same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" [TIME_T]. Therefore, the smallest absolute Time value that can be expressed (2**28) is 1978-07-04 21:24:16 UTC. Because Time values up to 2**28 are used for representing time relative to "now" and Time and Base Time are added together, care must be taken to ensure that the sum does not inadvertently reach 2**28 (i.e., absolute time) when relative time was intended to be used.
Top   ToC   RFC8428 - Page 11
   Obviously, SenML Records referenced to "now" are only useful within a
   specific communication context (e.g., based on information on when
   the SenML Pack, or a specific Record in a SenSML Stream, was sent) or
   together with some other context information that can be used for
   deriving a meaning of "now"; the expectation for any archival use is
   that they will be processed into UTC-referenced records before that
   context would cease to be available.  This specification deliberately
   leaves the accuracy of "now" very vague as it is determined by the
   overall systems that use SenML.  In a system where a sensor without
   wall-clock time sends a SenML Record with a time referenced to "now"
   over a high-speed RS-485 link to an embedded system with accurate
   time that resolves "now" based on the time of reception, the
   resulting time uncertainty could be within 1 ms.  At the other
   extreme, a deployment that sends SenML wind-speed readings over a
   Low-Earth Orbit (LEO) satellite link from a mountain valley might
   have resulting reception Time values that are easily a dozen minutes
   off the actual time of the sensor reading, with the time uncertainty
   depending on satellite locations and conditions.

4.5.4. Values

If only one of the Base Sum or Sum value is present, the missing field is considered to have a value of zero. The Base Sum and Sum values are added together to get the sum of measurement. If neither the Base Sum nor the Sum is present, then the measurement does not have a Sum value. If the Base Value or Value is not present, the missing field(s) is considered to have a value of zero. The Base Value and Value are added together to get the value of the measurement. Representing the statistical characteristics of measurements, such as accuracy, can be very complex. Future specification may add new fields to provide better information about the statistical properties of the measurement. In summary, the structure of a SenML Record is laid out to support a single measurement per Record. If multiple data values are measured at the same time (e.g., air pressure and altitude), they are best kept as separate Records linked through their Time value; this is even true when one of the data values is more "meta" than others (e.g., describes a condition that influences other measurements at the same time).
Top   ToC   RFC8428 - Page 12

4.6. Resolved Records

Sometimes it is useful to be able to refer to a defined normalized format for SenML Records. This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. Also, if SenML Records are used outside of a SenML Pack, they need to be resolved first to ensure applicable base values are applied. A SenML Record is referred to as "resolved" if it does not contain any base values, i.e., labels starting with the character "b", except for Base Version fields (see below), and has no relative times. To resolve the Records, the applicable base values of the SenML Pack (if any) are applied to the Record. That is, for the base values in the Record or before the Record in the Pack, Name and Base Name are concatenated, the Base Time is added to the time of the Record, the Base Unit is applied to the Record if it did not contain a Unit, etc. In addition, the Records need to be in chronological order in the Pack. An example of this is shown in Section 5.1.4. The Base Version field MUST NOT be present in resolved Records if the SenML version defined in this document is used; otherwise, it MUST be present in all the resolved SenML Records. A future specification that defines new base fields needs to specify how the field is resolved.

4.7. Associating Metadata

SenML is designed to carry the minimum dynamic information about measurements and, for efficiency reasons, does not carry significant static metadata about the device, object, or sensors. Instead, it is assumed that this metadata is carried out of band. For web resources using SenML Packs, this metadata can be made available using the CoRE Link Format [RFC6690]. The most obvious use of this link format is to describe that a resource is available in a SenML format in the first place. The relevant media type indicator is included in the Content-Type (ct=) link attribute (which is defined for the link format in Section 7.2.1 of [RFC7252]).

4.8. Sensor Streaming Measurement Lists (SenSML)

In some usage scenarios of SenML, the implementations store or transmit SenML in a stream-like fashion, where data is collected over time and continuously added to the object. This mode of operation is optional, but systems or protocols using SenML in this fashion MUST specify that they are doing this. SenML defines separate media types to indicate Sensor Streaming Measurement Lists (SenSML) for this
Top   ToC   RFC8428 - Page 13
   usage (see Section 12.3.2).  In this situation, the SenSML Stream can
   be sent and received in a partial fashion, i.e., a measurement entry
   can be read as soon as the SenML Record is received and does not have
   to wait for the full SenSML Stream to be complete.

   If times relative to "now" (see Section 4.5.3) are used in SenML
   Records of a SenSML Stream, their interpretation of "now" is based on
   the time when the specific Record is sent in the stream.

4.9. Configuration and Actuation Usage

SenML can also be used for configuring parameters and controlling actuators. When a SenML Pack is sent (e.g., using an HTTP/CoAP POST or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given (sub)resources (given as names) to given values at the given time(s). The semantics of the target resource supporting this usage can be described, e.g., using [RID-CoRE]. Examples of actuation usage are shown in Section 5.1.7.

5. JSON Representation (application/senml+json)

For the SenML fields shown in Table 2, the SenML Labels are used as the JSON object member names within JSON objects representing the JSON SenML Records. +---------------+-------+-----------+ | Name | Label | JSON Type | +---------------+-------+-----------+ | Base Name | bn | String | | Base Time | bt | Number | | Base Unit | bu | String | | Base Value | bv | Number | | Base Sum | bs | Number | | Base Version | bver | Number | | Name | n | String | | Unit | u | String | | Value | v | Number | | String Value | vs | String | | Boolean Value | vb | Boolean | | Data Value | vd | String | | Sum | s | Number | | Time | t | Number | | Update Time | ut | Number | +---------------+-------+-----------+ Table 2: JSON SenML Labels
Top   ToC   RFC8428 - Page 14
   The root JSON value consists of an array with one JSON object for
   each SenML Record.  All the fields in the above table MAY occur in
   the Records with member values of the type specified in the table.

   Only the UTF-8 [RFC3629] form of JSON is allowed.  Characters in the
   String Value are encoded using the escape sequences defined in
   [RFC8259].  Octets in the Data Value are base64 encoded with the URL-
   safe alphabet as defined in Section 5 of [RFC4648], with padding
   omitted.

   Systems receiving measurements MUST be able to process the range of
   floating-point numbers that are representable as IEEE double-
   precision, floating-point numbers [IEEE.754].  This allows Time
   values to have better than microsecond precision over the next 100
   years.  The number of significant digits in any measurement is not
   relevant, so a reading of 1.1 has exactly the same semantic meaning
   as 1.10.  If the value has an exponent, the "e" MUST be in lower
   case.  In the interest of avoiding unnecessary verbosity and speeding
   up processing, the mantissa SHOULD be less than 19 characters long,
   and the exponent SHOULD be less than 5 characters long.

5.1. Examples

5.1.1. Single Data Point

The following shows a temperature reading taken approximately "now" by a 1-wire sensor device that was assigned the unique 1-wire address of 10e2073a01080063: [ {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} ]

5.1.2. Multiple Data Points

The following example shows voltage and current "now", i.e., at an unspecified time. [ {"bn":"urn:dev:ow:10e2073a01080063:","n":"voltage","u":"V","v":120.1}, {"n":"current","u":"A","v":1.2} ]
Top   ToC   RFC8428 - Page 15
   The next example is similar to the above one, but it shows current at
   Tue Jun 8 18:01:16.001 UTC 2010 and at each second for the previous 5
   seconds.

   [
     {"bn":"urn:dev:ow:10e2073a0108006:","bt":1.276020076001e+09,
      "bu":"A","bver":5,
      "n":"voltage","u":"V","v":120.1},
     {"n":"current","t":-5,"v":1.2},
     {"n":"current","t":-4,"v":1.3},
     {"n":"current","t":-3,"v":1.4},
     {"n":"current","t":-2,"v":1.5},
     {"n":"current","t":-1,"v":1.6},
     {"n":"current","v":1.7}
   ]

   As an example of SenSML, the following stream of measurements may be
   sent via a long-lived HTTP POST from the producer of the stream to
   its consumer, and each measurement object may be reported at the time
   it was measured:

   [
     {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09,
      "bu":"%RH","v":21.2},
     {"t":10,"v":21.3},
     {"t":20,"v":21.4},
     {"t":30,"v":21.4},
     {"t":40,"v":21.5},
     {"t":50,"v":21.5},
     {"t":60,"v":21.5},
     {"t":70,"v":21.6},
     {"t":80,"v":21.7},
   ...

5.1.3. Multiple Measurements

The following example shows humidity measurements from a mobile device with a 1-wire address 10e2073a01080063, starting at Mon Oct 31 13:24:24 UTC 2011. The device also provides position data, which is provided in the same measurement or parameter array as separate entries. Note that time is used to correlate data that belongs together, e.g., a measurement and a parameter associated with it. Finally, the device also reports extra data about its battery status at a separate time.
Top   ToC   RFC8428 - Page 16
   [
     {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09,
      "bu":"%RH","v":20},
     {"u":"lon","v":24.30621},
     {"u":"lat","v":60.07965},
     {"t":60,"v":20.3},
     {"u":"lon","t":60,"v":24.30622},
     {"u":"lat","t":60,"v":60.07965},
     {"t":120,"v":20.7},
     {"u":"lon","t":120,"v":24.30623},
     {"u":"lat","t":120,"v":60.07966},
     {"u":"%EL","t":150,"v":98},
     {"t":180,"v":21.2},
     {"u":"lon","t":180,"v":24.30628},
     {"u":"lat","t":180,"v":60.07967}
   ]

   The following table shows the size of this example in various forms,
   as well as the size of each of these forms compressed with gzip.

                   +----------+------+-----------------+
                   | Encoding | Size | Compressed Size |
                   +----------+------+-----------------+
                   | JSON     | 573  |       206       |
                   | XML      | 649  |       235       |
                   | CBOR     | 254  |       196       |
                   | EXI      | 161  |       184       |
                   +----------+------+-----------------+

                         Table 3: Size Comparisons
Top   ToC   RFC8428 - Page 17

5.1.4. Resolved Data

The following shows the example from the previous section in resolved format. [ {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09, "v":20}, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09, "v":24.30621}, {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067464e+09, "v":60.07965}, {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067524e+09, "v":20.3}, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067524e+09, "v":24.30622}, {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067524e+09, "v":60.07965}, {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067584e+09, "v":20.7}, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067584e+09, "v":24.30623}, {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067584e+09, "v":60.07966}, {"n":"urn:dev:ow:10e2073a01080063","u":"%EL","t":1.320067614e+09, "v":98}, {"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067644e+09, "v":21.2}, {"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067644e+09, "v":24.30628}, {"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067644e+09, "v":60.07967} ]

5.1.5. Multiple Data Types

The following example shows a sensor that returns different data types. [ {"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":23.1}, {"n":"label","vs":"Machine Room"}, {"n":"open","vb":false}, {"n":"nfc-reader","vd":"aGkgCg"} ]
Top   ToC   RFC8428 - Page 18

5.1.6. Collection of Resources

The following example shows the results from a query to one device that aggregates multiple measurements from other devices. The example assumes that a client has fetched information from a device at 2001:db8::2 by performing a GET operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011 and has gotten two separate values as a result: a temperature and humidity measurement as well as the results from another device at http://[2001:db8::1] that also had a temperature and humidity measurement. Note that the last record would use the Base Name from the 3rd record but the Base Time from the first record. [ {"bn":"2001:db8::2/","bt":1.320078429e+09, "n":"temperature","u":"Cel","v":25.2}, {"n":"humidity","u":"%RH","v":30}, {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3}, {"n":"humidity","u":"%RH","v":67} ]

5.1.7. Setting an Actuator

The following example shows the SenML that could be used to set the current set point of a typical residential thermostat that has a temperature set point, a switch to turn on and off the heat, and a switch to turn on the fan override. [ {"bn":"urn:dev:ow:10e2073a01080063:"}, {"n":"temp","u":"Cel","v":23.1}, {"n":"heat","u":"/","v":1}, {"n":"fan","u":"/","v":0} ] In the following example, two different lights are turned on. It is assumed that the lights are on a network that can guarantee delivery of the messages to the two lights within 15 ms (e.g., a network using 802.1BA [IEEE802.1BA] and 802.1AS [IEEE802.1AS] for time synchronization). The controller has set the time of the lights to come on at 20 ms in the future from the current time. This allows both lights to receive the message, wait till that time, then apply the switch command so that both lights come on at the same time. [ {"bt":1.320078429e+09,"bu":"/","n":"2001:db8::3","v":1}, {"n":"2001:db8::4","v":1} ]
Top   ToC   RFC8428 - Page 19
   The following shows two lights being turned off using a
   non-deterministic network that has high odds of delivering a message
   in less than 100 ms and uses NTP for time synchronization.  The
   current time is 1320078429.  The user has just turned off a light
   switch that is turning off two lights.  Both lights are immediately
   dimmed to 50% brightness to give the user instant feedback that
   something is changing.  However, given the network, the lights will
   probably dim at somewhat different times.  Then 100 ms in the future,
   both lights will go off at the same time.  The instant, but not
   synchronized, dimming gives the user the sensation of quick
   responses, and the timed-off 100 ms in the future gives the
   perception of both lights going off at the same time.

   [
     {"bt":1.320078429e+09,"bu":"/","n":"2001:db8::3","v":0.5},
     {"n":"2001:db8::4","v":0.5},
     {"n":"2001:db8::3","t":0.1,"v":0},
     {"n":"2001:db8::4","t":0.1,"v":0}
   ]



(page 19 continued on part 2)

Next Section