Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+   SearchTech-invite World Map Symbol

RFC 8428

Proposed STD
Pages: 54
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: CORE

Sensor Measurement Lists (SenML)

Part 1 of 3, p. 1 to 19
None       Next Section

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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