Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Internet of Things (IoT) data model quantities and units International System of Units (SI) International System of Quantities (ISQ) The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry.

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 .

Copyright Notice Copyright (c) 2020 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 () 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

• .  Introduction
• .  New Primary Units
  • .  Rationale
• .  New Registry for Secondary Units
• .  Operational Considerations
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Author's Address

Introduction The Sensor Measurement Lists (SenML) media type supports the indication of a unit, using the SenML field "u", for the quantity given as a data value in a SenML record. For this purpose, SenML defines an IANA registry of defined unit names and their meanings; in the present document, we call the unit names registered there "primary unit names". This short document registers a number of additional units in the IANA registry for units in SenML that appear to be necessary for further adopting SenML in other Standards Development Organizations (SDOs). The document also defines a registry for secondary unit names that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry. Although SenML version 10 does not provide for the direct use of these secondary units, future support is intended via the use of SenML extension mechanisms, one of which is proposed in . 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.

New Primary Units IANA has assigned new units in the "SenML Units" subregistry of the "Sensor Measurement Lists (SenML)" registry (as defined in ): New Units Registered for SenML

Symbol	Description	Type	Reference
B	Byte (information content)	float	RFC 8798
VA	volt-ampere (Apparent Power)	float	RFC 8798
VAs	volt-ampere second (Apparent Energy)	float	RFC 8798
var	volt-ampere reactive (Reactive Power)	float	RFC 8798
vars	volt-ampere-reactive second (Reactive Energy)	float	RFC 8798
J/m	joule per meter (Energy per distance)	float	RFC 8798
kg/m3	kilogram per cubic meter (mass density, mass concentration)	float	RFC 8798
deg	degree (angle)*	float	RFC 8798

Rationale SenML takes the position that unscaled SI units should always be used. However, SenML makes one exception: The degree Celsius (as Cel) is allowed as an alternative to the K (Kelvin). This document takes the position that the same should apply to a small number of alternative units in wide use:

The Byte:

defines both the bit (item 13-9.b) and the byte (item 13-9.c, also called octet) as alternative names for the coherent unit used for dimensionless quantities, for the purpose of giving storage capacity and related quantities. While the name octet is associated with the symbol o, this is in wide use only in French-speaking countries. Globally more widespread is the symbol B for byte, even though B is already taken in SI for bel. therefore registers dB as the SenML unit for logarithmic relative power, leaving B free for the usage proposed here. While this is potentially confusing, the situation is widely understood in engineering circles and is unlikely to cause actual problems.

The Volt-Ampere:

defines the volt ampere (VA) (item 6-57.a) as a unit for apparent power; items 6-59.a, 6-60.a, and 6-61.a also use the unit for complex, reactive, and non-active power.

The Volt-Ampere Reactive:

item 6-60.b defines the volt-ampere reactive (var) as an alternative (and fully equivalent) unit to VA specifically for reactive power (with the primary unit VA); it has become clear that there is strong interest in using this unit specifically for the imaginary content of complex power, i.e., reactive power .

The Joule per meter is not a traditional electromagnetic unit. It and its scaled derivatives (in particular Wh/km) are used to describe the energy expended for achieving motion over a given distance, e.g., as an equivalent for electrical cars of the inverse of "mileage". The unit "degree" is in wide use in practice for plane angles (as in heading, bearing, etc.). It is marked with an asterisk because the preferred coherent SI unit is radian ("rad").

New Registry for Secondary Units IANA has created a "Secondary Units" subregistry in the "Sensor Measurement Lists (SenML)" registry defined in . The registry has six columns:

• Secondary Unit: a newly registered name allocated within the same namespace as SenML units
• Description: a short description (usually just the expansion of an abbreviation)
• SenML Unit: an existing SenML unit from the SenML Units registry
• Scale, Offset: two rational numbers, expressed in decimal (optionally, with a decimal exponent given) or as a fraction represented using a "/" character to separate numerator and denominator
• Reference: where the entry comes from

Quantities expressed in the secondary unit can be converted into the SenML unit by first multiplying their value with the scale number and then adding the offset, yielding the value in the given SenML unit. The initial content of the "Secondary Units" subregistry is provided in : Secondary Units Registered for SenML

Secondary Unit	Description	SenML Unit	Scale	Offset	Reference
ms	millisecond	s	1/1000	0	RFC 8798
min	minute	s	60	0	RFC 8798
h	hour	s	3600	0	RFC 8798
MHz	megahertz	Hz	1000000	0	RFC 8798
kW	kilowatt	W	1000	0	RFC 8798
kVA	kilovolt-ampere	VA	1000	0	RFC 8798
kvar	kilovar	var	1000	0	RFC 8798
Ah	ampere-hour	C	3600	0	RFC 8798
Wh	watt-hour	J	3600	0	RFC 8798
kWh	kilowatt-hour	J	3600000	0	RFC 8798
varh	var-hour	vars	3600	0	RFC 8798
kvarh	kilovar-hour	vars	3600000	0	RFC 8798
kVAh	kilovolt-ampere-hour	VAs	3600000	0	RFC 8798
Wh/km	watt-hour per kilometer	J/m	3.6	0	RFC 8798
KiB	kibibyte	B	1024	0	RFC 8798
GB	gigabyte	B	1e9	0	RFC 8798
Mbit/s	megabit per second	bit/s	1000000	0	RFC 8798
B/s	byte per second	bit/s	8	0	RFC 8798
MB/s	megabyte per second	bit/s	8000000	0	RFC 8798
mV	millivolt	V	1/1000	0	RFC 8798
mA	milliampere	A	1/1000	0	RFC 8798
dBm	decibel (milliwatt)	dBW	1	-30	RFC 8798
ug/m3	microgram per cubic meter	kg/m3	1e-9	0	RFC 8798
mm/h	millimeter per hour	m/s	1/3600000	0	RFC 8798
m/h	meter per hour	m/s	1/3600	0	RFC 8798
ppm	parts per million	/	1e-6	0	RFC 8798
/100	percent (Note 1)	/	1/100	0	RFC 8798
/1000	permille	/	1/1000	0	RFC 8798
hPa	hectopascal	Pa	100	0	RFC 8798
mm	millimeter	m	1/1000	0	RFC 8798
cm	centimeter	m	1/100	0	RFC 8798
km	kilometer	m	1000	0	RFC 8798
km/h	kilometer per hour	m/s	1/3.6	0	RFC 8798

Example: The value of a quantity given as 100 ms is first multiplied by 1/1000, yielding the number 0.1, and the offset 0 is then added, yielding the number 0.1 again, leading to a quantity of 0.1 s. The value of a quantity given as 10 dBm is first multiplied by 1, yielding the number 10, and the offset -30 is then added, yielding the number -20, leading to a quantity of -20 dBW. New entries can be added to the registration by Expert Review as defined in . Experts should exercise their own good judgment, with the same guidelines as used for SenML units (), but without applying rules 4, 5, and 8. Note that rule 7 limits the use of what could be understood as prefixes on their own, not the use of prefixes inside secondary unit names. Guidelines to the difference between units (which can go into the registry) and quantities (which cannot) are widely available; see, for instance, and . As of SenML version 10 , SenML packs are limited to using primary units in "u" fields. The use of primary units enables direct comparison of measurements from different sources. Also, it facilitates implementations that trigger on the presence of a quantity in a certain unit, without the need to track any additional secondary units that may be registered for this quantity. Where the benefits of directly using a secondary unit in a SenML pack outweigh the above considerations, the use of secondary units in "u" fields MAY be enabled by indicating a new SenML version that specifically allows this and/or by using a field with a label name that ends with the "_" character ("must-understand" field) whose definition specifically allows this. The definition of these versions and fields is outside the scope of the present specification; one such definition is proposed in .

Operational Considerations The "Secondary Units" subregistry is expected to grow at a faster pace than the subregistry of primary unit names. It also is amenable to automatic interpretation, by making use of the scale and offset columns. Implementers may be tempted to equip each instance of their systems with code to download new versions of the registry from IANA frequently in order to be able to make use of newly defined secondary unit names. This can create high load at IANA and a potential single point of failure. Instead of pulling the registry in each individual instance of the code, the software update mechanism (or a similar mechanism that leads to less frequent IANA visits) SHOULD be used to disseminate updated units registries obtained from IANA towards the instances via common repositories.

Security Considerations The security considerations of apply. The introduction of new measurement units poses no additional security considerations except a potential for additional confusion about the proper unit to use and the risk that an implementation based on the assumption described in the penultimate paragraph of no longer works properly. However, an implementation processing a pack while making use of secondary units is guaranteed to have been developed with an awareness of the risks of having multiple units available for the same logical type. In any case, the existing risk of an existing SenML implementation not understanding a unit that was not in the initial registry content provided in is unchanged, and implementations are warned properly about the potential use of secondary units by the need for a must-understand field or an updated version field.

IANA Considerations See and .

References Normative References IANA IEC Edition 1.0 IEC Edition 1.0 IEEE In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. 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. Informative References Bureau International des Poids et Mesures 9th edition version 1.06 Rohde & Schwarz version 5.0 This short document updates RFC 8428, Sensor Measurement Lists (SenML), by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers. Work in Progress

Acknowledgements pointed out the need for additional units in SenML. Comments provided by him as well as by , , , , and helped improve the document.

Author's Address Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org