Lightweight Machine to Machine Technical Specification: Transport Bindings
Candidate Version: 1.1 - 12 Jun 2018
Open Mobile Alliance
OMA-TS-LightweightM2M_Transport-V1_1-20180612-C
master: 18 Jun 2018 19:20:00 rev: 11d8925

Use of this document is subject to all of the terms and conditions of the Use Agreement located at https://www.omaspecworks.org/about/policies-and-terms-of-use/use-agreement/.

Unless this document is clearly designated as an approved specification, this document is a work in process, is not an approved Open Mobile Alliance™ specification, and is subject to revision or removal without notice.

You may use this document or any part of the document for internal or educational purposes only, provided you do not modify, edit or take out of context the information in this document in any manner. Information contained in this document may be used, at your sole risk, for any purposes. You may not use this document in any other manner without the prior written permission of the Open Mobile Alliance. The Open Mobile Alliance authorizes you to copy this document, provided that you retain all copyright and other proprietary notices contained in the original materials on any copies of the materials and that you comply strictly with these terms. This copyright permission does not constitute an endorsement of the products or services. The Open Mobile Alliance assumes no responsibility for errors or omissions in this document.

Each Open Mobile Alliance member has agreed to use reasonable endeavors to inform the Open Mobile Alliance in a timely manner of Essential IPR as it becomes aware that the Essential IPR is related to the prepared or published specification. However, the members do not have an obligation to conduct IPR searches. The declared Essential IPR is publicly available to members and non-members of the Open Mobile Alliance and may be found on the “OMA IPR Declarations” list at https://www.omaspecworks.org/about/intellectual-property-rights/. The Open Mobile Alliance has not conducted an independent IPR review of this document and the information contained herein, and makes no representations or warranties regarding third party IPR, including without limitation patents, copyrights or trade secret rights. This document may contain inventions for which you must obtain licenses from third parties before making, using or selling the inventions. Defined terms above are set forth in the schedule to the Open Mobile Alliance Application Form.

NO REPRESENTATIONS OR WARRANTIES (WHETHER EXPRESS OR IMPLIED) ARE MADE BY THE OPEN MOBILE ALLIANCE OR ANY OPEN MOBILE ALLIANCE MEMBER OR ITS AFFILIATES REGARDING ANY OF THE IPR’S REPRESENTED ON THE “OMA IPR DECLARATIONS” LIST, INCLUDING, BUT NOT LIMITED TO THE ACCURACY, COMPLETENESS, VALIDITY OR RELEVANCE OF THE INFORMATION OR WHETHER OR NOT SUCH RIGHTS ARE ESSENTIAL OR NON-ESSENTIAL.

THE OPEN MOBILE ALLIANCE IS NOT LIABLE FOR AND HEREBY DISCLAIMS ANY DIRECT, INDIRECT, PUNITIVE, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES ARISING OUT OF OR IN CONNECTION WITH THE USE OF DOCUMENTS AND THE INFORMATION CONTAINED IN THE DOCUMENTS.

© 2018 Open Mobile Alliance All Rights Reserved. Used with the permission of the Open Mobile Alliance under the terms set forth above.

Table of Contents

Table of Figures

Table of Tables

1. Scope

This document specifies the transport bindings of the Lightweight Machine-to-Machine (LwM2M) protocol version 1.1. The split between the LwM2M core [LwM2M-CORE] and the transport binding specification improves readability, allows a cleaner separation between the LwM2M messaging layer and the underlying protocols for conveying these messages, and ultimately better extensibility.

LwM2M version 1.0 supported multiple transport bindings, namely CoAP over UDP, and over SMS. The UDP and SMS transports can be used with or without DTLS. This specification, LwM2M version 1.1, adds support for CoAP over TCP / TLS, and CoAP over Non-IP, namely 3GPP CIoT and LoRaWAN. CoAP over TCP / TLS, as defined in [CoAP_TCP], offers better firewall traversal, as explained in Section 1 of [CoAP_TCP].

This specification also supports the application layer security protocol OSCORE [OSCORE] which enables support for proxy operations and end-to-end security independently of transport layer protocol.

2. References

2.1. Normative References

Table: 2.1.-1 Normative References
[3GPP-TS_23.003] 3GPP TS 23.003 "Numbering, addressing and identification"
[CoAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "The Constrained Application Protocol (CoAP)", RFC 7252, Jun. 2014.
[CoAP_Blockwise] C. Bormann, Z. Shelby, "Block-wise transfers in CoAP", RFC 7959, Aug. 2016.
[CoAP_TCP] C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, Feb. 2018.
[CoAP_ERT] C. Amsuess, J. Mattsson, G. Selander, "Echo and Request-Tag", draft-ietf-core-echo-request-tag-00, Oct. 2017.
[CoAP-EST] P. van der Stok, et al., "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap-est-00, Feb., 2018
[CoRE_Interface] Z. Shelby, M. Vial, "CoRE Interfaces", draft-ietf-core-interfaces-01, Nov. 2013.
[ETSI TS 102.221] "Smart Cards; UICC-Terminal interface; Physical and logical characteristics", (ETSI TS 102 221 release 11), URL:http://www.etsi.org/
[ETSI TS 102.223] "Smart Cards; Card Applications Toolkit (CAT) (Release 11)", URL:http://www.etsi.org/
[ETSI TS 102.225] ETSI TS 102 225 (V11.0.0): "Smart Cards; Secured packet structure for UICC based applications (Release 11)" URL:http://www.etsi.org/
[GLOBALPLATFORM] GlobalPlatform v2.2.1 - January 2011 -
[GP SCP03] GlobalPlatform Secure Channel Protocol 03 (SCP 03) Amendment D v1.1 Sept 2009
[OBSERVE] Hartke, K. "Observing Resources in CoAP", RFC 7641, Sep. 2015.
[OSCORE] G. Selander, J. Mattsson, F. Palombini, L. Seitz, "Object Security for Constrained RESTful Environments", draft-ietf-core-object-security-08, Jan. 2018.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Mar. 1997.
[RFC5246] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, Aug. 2008.
[RFC5280] D. Cooper, et al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5289] E. Rescorla, "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, Aug. 2008.
[RFC5487] M. Badra, Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode, Mar. 2009.
[RFC5869] H. Krawczyk, P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, Jan. 2012.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for TLS", RFC 6655, Jul. 2012.
[RFC6690] Shelby, Z. "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, Aug. 2012.
[WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram Protocol", June 2001.
[RFC7925] H. Tschofenig, T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, Jul. 2016.
[RFC8075] A. Castellani, et al., "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, Feb. 2017.
[RFC8152] J. Schaad, "CBOR Object Signing and Encryption (COSE)", RFC 8152, Jul. 2017.
[LwM2M-CORE] Open Mobile Alliance, "Lightweight Machine to Machine Technical Specification: Core Layer", (work in progress), Dec. 2017.
[RFC5958] S. Turner, "Asymmetric Key Packages", RFC 5958, August 2010.
[RFC7366] P. Gutmann, "Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7366, September 2014.
[RFC8132] P. van der Stok, C. Bormann, A. Sehgal, "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)", RFC 8132, APril 2017.
[SCRRULES] "SCR Rules and Procedures", Open Mobile Alliance™, OMA-ORG-SCR_Rules_and_Procedures, URL:http://member.openmobilealliance.org/ftp/Public_documents/iop/Permanent_documents/OMA-ORG-SCR_Rules_and_Procedures-V1_0-20060919-A.zip
[3GPP-TS_31.115] 3GPP TS 31.115 "Secured packet structure for (Universal) Subscriber Identity Module (U)SIM Toolkit applications"

2.2. Informative References

Table: 2.2.-1 Informative References
[3GPP-TR_21.905] 3GPP TR 21.905 Vocabulary for 3GPP Specifications
[OMADICT] "Dictionary for OMA Specifications", Open Mobile Alliance™, OMA-ORG-Dictionary-V2_9, URL:http://www.openmobilealliance.org/
[RFC4086] D. Eastlake, J. Schiller, S. Crocker, "Randomness Requirements for Security", RFC 4086, June 2005.
[RFC7457] Y. Sheffer, R. Holz, and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, February 2015.
[SP800-90A] Elaine Barker, John Kelsey, "Recommendation for Random Number Generation Using Deterministic Random Bit Generators, NIST Special Publication 800-90A", Revision 1, June 2015, available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
[LoRaWAN] The LoRa Alliance, "LoRaWAN 1.1 Specification", available at https://www.lora-alliance.org/lorawan-for-developers
[RFC6961] Pettersen, Y. "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, June 2013.

3. Terminology and Conventions

3.1. Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

All sections and appendixes, except "Scope" and "Introduction", are normative, unless they are explicitly indicated to be informative.

3.2. Definitions

Table: 3.2.-1 Definitions
LwM2M Bootstrap-Server Account LwM2M Security Object Instance with Bootstrap-Server Resource set to 'true'.
LwM2M Server Account LwM2M Security Object Instance with Bootstrap-Server Resource set to 'false' and associated LwM2M Server Object Instance.

Kindly consult [OMADICT] for more definitions used in this document.

3.3. Abbreviations

    </tbody>            
Table: 3.3.-1 Abbreviations
CoAP Constrained Application Protocol
DTLS Datagram Transport Layer Security
TLS Transport Layer Security
UDP User Datagram Protocol
SMS Short Message Service
TCP Transmission Control Protocol
LoRaWAN LOng RAnge Wide Area Network
NB-IoT NarrowBand Internet of Things
OCSP Online Certificate Status Protocol

4. Introduction

This specification defines the transport bindings for the LwM2M messaging protocol used between LwM2M Clients, LwM2M Bootstrap Servers and LwM2M Servers. Figure: 4.-1 The Protocol Stack of the LwM2M Enabler shows the relationships between the transport bindings and the messaging protocol. In particular, this specification defines the following transport bindings:

The Protocol Stack of the LwM2M Enabler
Figure: 4.-1 The Protocol Stack of the LwM2M Enabler

OSCORE can be used with any of the transport bindings including UDP, SMS and TCP, with or without DTLS or TLS.

5. Security

The LwM2M protocol supports various transport bindings and credentials for securely communicating with LwM2M Servers. This configuration information can be provisioned through various forms of bootstrapping methods.

LwM2M supports three different types of credentials, namely

Since these credential types offer different properties, the LwM2M specification offers support for all of them. [RFC7925] provides the necessary details about the use of each of these credentials with TLS/DTLS. The LwM2M specification also supports application layer security based on OSCORE with pre-shared secrets. Which credential is best in a given deployment depends on a number of factors, including the threat model and IoT device constraints.

The LwM2M protocol specifies that authorization of LwM2M Servers to access Object Instances and Resources within the LwM2M Client is provided through Access Control Object Instances within the LwM2M Client.

5.1. Security Requirements

LwM2M may under certain circumstances be deployed with security outside the scope of LwM2M TS, as specified in other parts of this section. However, for LwM2M security solutions the requirements specified in this section apply.

The LwM2M protocol requires that all communication between LwM2M Clients, LwM2M Servers and LwM2M Bootstrap-Servers to perform mutual authentication. This means:

The LwM2M protocol also requires that all communication between LwM2M Clients and LwM2M Servers as well as between LwM2M Clients and LwM2M Bootstrap-Servers is encrypted and integrity protected. This means:

Additionally:

The security requirements applies also to communication via LwM2M aware and LwM2M unaware intermediate nodes.

In addition to communication security care must also be taken to ensure that data at rest, such as secrets and sensor data, are also secured against unauthorized access.

5.2. TLS/DTLS-based Security

5.2.1. TLS/DTLS Overview

CoAP over UDP [CoAP] is secured using the Datagram Transport Layer Security (DTLS) 1.2 protocol [RFC6347], as defined in Section 9 of [CoAP]. DTLS is a communication security solution for datagram based protocols (such as UDP). More recently support for CoAP over TCP / TLS has been defined in [CoAP-TCP]. TLS 1.2 is specified in [RFC5246]. TLS and DTLS provide mutual authentication, data integrity and confidentiality.

This section provides information related to the use of CoAP over DTLS and CoAP over TLS. Section 5.4. SMS Channel Security provides additional information regarding the use of DTLS in an SMS context. Implementations SHOULD be conformant to [RFC7925], which includes not only ciphersuites but also recommendations for the use of TLS/DTLS-specific extensions.

The TLS/DTLS client and the TLS/DTLS server SHOULD keep security state, such as session keys, sequence numbers, and initialization vectors, and other security parameters, established with TLS/DTLS for as long a period as can be safely achieved without risking compromise of the security context. If such state persists across sleep cycles where the RAM is powered off, secure storage SHOULD be used for the security context.

The credentials used for authenticating the TLS/DTLS client and the TLS/DTLS server to secure the communication between the LwM2M Client and the LwM2M Server are obtained using one of the bootstrap modes defined in [LwM2M-CORE].

LwM2M Bootstrap-Servers, LwM2M Servers and LwM2M Clients MUST use different key pairs. LwM2M Clients MUST use keys, which are unique to each LwM2M Client. When a LwM2M Client is configured to utilize multiple LwM2M Servers then the LwM2M Bootstrap-Server may configure different credentials with these LwM2Ms Servers. Using different credentials with each LwM2M Server provides better unlinkability properties since each individual LwM2M Server cannot correlate requests made by the LwM2M Client to other LwM2M Servers. Deployment and application specific considerations dictate what approach to use, but using different credentials is generally recommended practice.

5.2.2. Ciphersuites

TLS/DTLS supports the concept of ciphersuites and they are securely negotiated during the handshake. This specification recommends support of a limited number of ciphersuites based on [RFC7925]. These ciphersuites have been chosen because of suitability for IoT devices, security reasons and to improve interoperability. Ciphersuites in TLS/DTLS 1.2 depend on the type of credential being used since the ciphersuite concept also indicates the authentication and key exchange mechanism. LwM2M Clients and LwM2M Servers MAY support additional ciphersuites that conform to the state-of-the-art security requirements.

5.2.3. Elliptic Curves

For ECDHE, the group secp256r1 SHALL be supported. For ECDSA the curve secp256r1 SHALL be supported. Elliptic curve groups of less than 255 bits SHALL not be supported.

5.2.4. Bootstrapping

The Resources in the LwM2M Security Object are used for

  1. providing TLS/DTLS communication security for "Client Registration", "Device Management & Service Enablement", and "Information Reporting" Interfaces if the LwM2M Security Object Instance relates to a LwM2M Server, or,

  2. providing channel security for the Bootstrap interface if the LwM2M Security Object instance relates to a LwM2M Bootstrap-Server.

  3. protecting the communication with a firmware repository when the LwM2M Client receives a URI in the Package URI of the Firmware Update object.

The content and the interpretation of the Resources in the LwM2M Security Object depends on the type of credential being used.

When bootstrapping from a Smartcard a secure channel between the Smartcard and the LwM2M Client SHOULD be established, as described in Appendix G and defined in [GLOBALPLATFORM 3], [GP SCP03]. Using a Smartcard with pre-shared secrets, with raw public keys, and with certificates needs no pre-existing trust relationship between LwM2M Server(s) and LwM2M Client(s): the pre-established trust relationship exists between the LwM2M Server(s) and the SmartCard.

LwM2M Clients MUST either be provisioned for use with a LwM2M Server or else be provisioned for use with a LwM2M Bootstrap-Server. Any LwM2M Client, which supports the client initiated bootstrap mode, MUST support at least one of the following secure methods:

  1. Bootstrapping with a strong (high-entropy) pre-shared secret, as described in Section 5.2.8.1. Pre-Shared Keys. The ciphersuites defined in Section 5.2.8.1. Pre-Shared Keys MUST NOT be used with a low-entropy secret or with a password.

  2. Bootstrapping with a raw public key or a certificate, as described in Section 5.2.8.2. Raw Public Keys and Section 5.2.8.3. X.509 Certificates.

LwM2M Clients MUST be provisioned with credentials that are unique to their device. For full interoperability in all deployment environments, a LwM2M Bootstrap-Server MUST support bootstrapping via pre-shared secrets, raw public keys, and certificates.

NOTE: The LwM2M Bootstrap-Server can also provision KIc and KID for the use of SMS Secured Packet Structure mode (see Section 5.4. SMS Channel Security).

Security credential dynamically provisioned to the LwM2M Client and the LwM2M Server MAY change at any time, even during the lifetime of an ongoing TLS/DTLS session. Since the TLS/DTLS protocol verifies the credentials only at the beginning of the session establishment (unless the re-negotiation feature is used) it is possible that a change in credential (for example, credentials for the use of a PSK-based ciphersuite) occurs after a TLS/DTLS handshake has already been completed. Hence, from a TLS/DTLS protocol point of view such credential change is not automatically recognized and the already established record layer security associations are in use. It is a policy decision for a TLS/DTLS client as well as a TLS/DTLS server implementation to close a connection when the credentials change. Such a decision will depend on various factors, such as the application domain in which LwM2M is used. The LwM2M specification does not mandate a specific behaviour since TLS/DTLS allows both communication parties to tear down an established TLS/DTLS session for any number of reasons.

The Security Mode Resource in the Security Object determines what credentials are being used by the LwM2M Client and the LwM2M Server or LwM2M Bootstrap-Server, respectively. Currently five security modes are defined, namely

The Enrollment over Secure Transport (EST) bootstrap mode is a certificate management protocol for provisioning certificates from the LwM2M Bootstrap-Server to the LwM2M Client. EST allows the LwM2M Client to generate the key pair locally on the LwM2M Device. The private key therefore never leaves the LwM2M Device. In order to use this mode the "Security Mode" Resource MUST be set to value 4 and the certificate of the TLS/DTLS server MUST be provisioned to the "Server Public Key" Resource. This triggers the LwM2M Client to locally generate a public / private key pair and to initiate an EST over CoAP protocol exchange [CoAP-EST] to obtain a certificate. Once the certificate has been obtained it behaves like the Certificate mode. The EST over CoAP specification [CoAP-EST] profiles the use of EST for use in constrained environments.

Generating high quality random numbers of IoT devices, which is required by the EST mode utilized by this specification, is often a concern. When generating a public / private key pair, the random generator used by the LwM2M Client MUST respect the characteristics of a sufficiently high quality random bit generator, such as defined for example by RFC 4086 [RFC4086] or NIST Special Publication 800-90A Revision 1 [SP800-90A].

Compared to the certificate mode with the "Security Mode" Resource set to value 2 additional over-the-air overhead is introduced by this mode since the LwM2M Client needs to convey the public key to the EST server and needs to demonstrate possession of the private key using the PKCS#10 defined mechanism, as explained in the EST specification. Depending on the deployment environment this additional overhead needs to be compared against the added security benefit of not disclosing the private key to other parties. LwM2M Clients SHOULD use an existing key pair or generate the public/private key pair locally since this does not expose the private key to the LwM2M Bootstrap-Server or other parties, i.e., the private key pair SHOULD never leave the device.

Note: The "Secret Key" and the "Public Key or Identity" Resources are not used by the Certificate mode with EST.

Enrollment over Secure Transport (EST) offers multiple features, including

but only the first two are mandatory to implement when the EST over CoAP is used for bootstrapping since the functionality for server-generated key requests is already covered as part of the security mode (1 - Raw Public Key mode and 2 - Certificate mode). CSR Attributes Request is also not required for this specification since the LwM2M Bootstrap Server is typically in possession of the required attributes for generating a certificate.

5.2.5. Unbootstrapping

The term 'unbootstrapping' refers to the process of deleting an instance of a LwM2M Security Object. If such an instance of a Security Object is to be deleted related resources and configurations need to be deleted or modified as well. This ensures that there is no orphan data, for example LwM2M Server Object instances with no security context. Therefore, when the Delete operation is sent via the Bootstrap Interface, the Client MUST execute the following procedure.

  1. The Server Object Instance, which the deleted Security Object referred to, MUST be deleted. The Client MAY send the "De-register" operation to the LwM2M Server.

  2. If there is an Object Instance that can be accessed only by a LwM2M Server of the Server Object Instance (i.e., the LwM2M Server is Access Control Owner and the LwM2M Server can access the Object Instance only in an Access Control Object Instance), the Object Instance and the corresponding Access Control Object Instance MUST be deleted.

  3. If an Object Instance can be accessed by multiple LwM2M Servers including the LwM2M Server which Security Object Instance is to be deleted, then

  1. Observation operations from the LwM2M Server Object Instance MUST be deleted.

Note: To monitor the change of the Access Control Owner the LwM2M Server MAY observe the Access Control Owner Resource.

5.2.6. Endpoint Client Name

This specification recommends, but does not mandate, transmission of the endpoint client name in the Bootstrap-Request and in the Register message. Since the endpoint client name is not authenticated at the application layer the LwM2M Server MUST compare the received endpoint client name identifier with the identifier used at the TLS/DTLS handshake. This comparison may either be an equality match or may involve a dedicated lookup table to ensure that LwM2M Clients cannot intentionally or due to misconfiguration impersonate other LwM2M Clients. The LwM2M Server MUST respond with a "4.00 Bad Request" to the LwM2M Client if these fields do not match.

5.2.7. LwM2M and TLS/DTLS Roles

In LwM2M version 1.1 the LwM2M Client is always the TLS/DTLS client. The LwM2M Bootstrap-Server and the LwM2M Server are always acting as TLS/DTLS servers.

5.2.8. Credential Types

[RFC7925] gives recommendations for three types of credentials, namely pre-shared keys, raw public keys, and X.509 certificates. LwM2M works with all three types of credentials but the performance and security trade-offs for these three mechanisms are different. As a summary, the three credential types have the following properties:

The following sub-sections define the use of various resources in the LwM2M Security Object for the specific credential types. The "LwM2M Server URI", and the "Bootstrap Server" Resources are populated according to the description in [LwM2M-CORE].

5.2.8.1. Pre-Shared Keys

If a LwM2M Server supports the pre-shared key credentials it MUST support the following:

The LwM2M Client SHOULD NOT use the TLS_PSK_WITH_AES_128_CBC_SHA256 ciphersuite as RFC 7457 [RFC7457] has identified security attacks against these TLS/DTLS ciphersuites.

A LwM2M v1.1 Client MUST support TLS_PSK_WITH_AES_128_CCM_8 and MAY support additional ciphersuites.

This mode requires the following resources of the Security Object to be populated:

5.2.8.2. Raw Public Keys

If a LwM2M Server supports the raw public key credentials it MUST support the following:

The LwM2M Client SHOULD NOT use the TLS_PSK_WITH_AES_128_CBC_SHA256 ciphersuite as RFC 7457 [RFC7457] has identified security attacks against these TLS/DTLS ciphersuites.

A LwM2M v1.1 Client MUST support TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and MAY support additional ciphersuites. Ciphersuites SHOULD have ECDSA authentication and SHOULD have ECDHE key exchange.

This mode requires the following resources of the Security Object to be populated:

This security mode is appropriate for LwM2M deployments where the benefits of asymmetric cryptography are needed but the PKI functionality is undesireable.

The TLS/DTLS client MUST check that the raw public key presented by the TLS/DTLS server matches this stored public key.

The TLS/DTLS server MUST store its own private and public keys, and MUST have a stored copy of the expected client public key. The TLS/DTLS server MUST check that the raw public key presented by the TLS/DTLS client exactly matches this stored public key.

5.2.8.3. X.509 Certificates

The X.509 Certificate mode requires the use of X.509v3 certificates [RFC5280]. The X.509 certificates SHOULD be conformant with the profiling given in [RFC7925]. The curve secp256r1 SHALL be supported. Elliptic curve groups of less than 255 bits SHALL NOT be supported.

If a LwM2M Server supports X.509 Certificate mode it MUST support:

The LwM2M Client SHOULD NOT use the TLS_PSK_WITH_AES_128_CBC_SHA256 ciphersuite as RFC 7457 [RFC7457] has identified security attacks against these TLS/DTLS ciphersuites.

A LwM2M v1.1 Client MUST support TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and MAY support additional ciphersuites. Ciphersuites SHOULD have ECDSA authentication and SHOULD have ECDHE key exchange.

This mode requires the following resources of the Security Object to be populated:

When certificate-based authentication is used in TLS/DTLS to protect the LwM2M communication at least two types of certificates need to be distinguished, namely client (or device) certificates and certificates presented by the server. This distinction matters since the identifiers used in the certificates will be different and the procedure for identifier matching will be different as well. The subsequent text talks about the certificates used by the server.

The algorithm for verifying the service identity, as described in Section 4.4.1 of [RFC7925] and in [RFC6125], is essential for ensuring proper security when certificates are used and MUST be implemented and used by the TLS/DTLS client. Terms like reference identifier and presented identifier are defined in RFC 6125.

Comparing the reference identifier against the presented identifier obtained from the certificate is required to ensure the TLS/DTLS client is communicating with the intended TLS/DTLS server. To cater for the case that the Server Public Key Resource directly contains the certificate of the TLS/DTLS server, TLS/DTLS client does not compare the reference identifier against the presented identifier if the certificate from the Server Public Key Resource matches the certificate provided by the TLS/DTLS server during the TLS/DTLS handshake. If that is not the case, the TLS/DTLS client MUST compare the reference identifier against the presented identifier as described below, and perform path validation.

The algorithm description from RFC 6125 assumes that fully qualified DNS domain names (FQDN) are used. If a server node is provisioned with a FQDN, then the TLS/DTLS server certificate MUST contain this "FQDN" (i.e., presented identifier). This FQDN is stored in the SubjectAltName or in the Common Name (CN) component of the subject name, as explained in Section 9.1.3.3 of [RFC7252], and this FQDN is used by the TLS/DTLS client to match it against the FQDN used during the lookup process (i.e., reference identifier) before contacting the LwM2M Server, as described in [RFC6125].

Note that the Server Name Indication (SNI) extension [RFC6066] allows a TLS/DTLS client to tell a TLS/DTLS server the name of the TLS/DTLS server it is trying to contact. This is an important feature when the server is part of a hosting solution where multiple virtual servers are using a single underlying network address. Section 3 of [RFC6066] only allows FQDN hostname of the TLS/DTLS server in the ServerName field. For the TLS/DTLS client running on a LwM2M Server the SNI extension allows the LwM2M Server to indicate what certificate it is expecting. The SNI extension MUST be set by the LwM2M client.

5.2.8.4. Deployments without DNS

In some deployment scenarios, DNS is not used and LwM2M Clients need to use the IP literal, such as coaps://[2001:db8::2:1]/, stored in the "LwM2M Server URI" Resource. To avoid having to use IP addresses also in the Common Name (CN) component of the server certificate or in a field of URI type in the SubjectAltName set this specification uses the Server Name Indication (SNI) Resource.

The procedure for a client is as follows:

5.2.8.5. Certificate Expiry

For the use of certificates devices need to be equipped with a real-time clock and need to be provisioned with a reference time since the certificate expiry field needs to be checked.

If the Bootstrap-Server certificate has an expiration time then out-of-band mechanisms may be used to recover from an expired certificate. The LwM2M specification does not offer a way to recover from an expired Bootstrap-Server certificate. Out-of-band mechanism may include replacing the LwM2M Bootstrap-Server certificate via the firmware update mechanism or using a commissioning tool.

The LwM2M Bootstrap-Server or an authorized LwM2M Server MAY use the Current Time Resource of the LwM2M Device Object to provision a date/time reference value to the LwM2M Client. The LwM2M Client SHOULD verify the freshness of the request for setting the Current Time Resource. The LwM2M Client can use this reference value together with the current real-time clock setting to determine the current time to check the expiry date of a LwM2M Server certificate. The ability to modify the value of the Current Time Resource is security critical and therefore appropriate access control settings need to be applied.

5.2.8.6. Certificate Revocation

A LwM2M Client needs to determine when a LwM2M Server certificate has been revoked. Various approaches for dealing with expired LwM2M Server certificates are possible and the most promising candidates are:

  1. The LwM2M Client MAY use the error recovery procedures that will be invoked when a TLS / DTLS client encounters a problem verifying the LwM2M Server certificate during the handshake.

  2. The LwM2M Client MAY use the Online Certificate Status Protocol (OCSP) as part of the OCSP stapling mechanism [RFC6961]. This does, however, assume that the LwM2M Client and the LwM2M Server regularly execute the TLS / DTLS handshake, which may depend on the deployment. Note that the OCSP stapling comes with an extra cost of conveying the OCSP information inside the TLS / DTLS handshake.

  3. The server-initiated bootstrapping procedure is used by a LwM2M infrastructure operator to trigger a LwM2M Client to re-run the bootstrapping exchange to obtain new credentials for use with LwM2M Servers. The server-initiated bootstrapping procedure may not be usable by the LwM2M Server that has gotten its certificate revoked.

If the Bootstrap-Server certificate has been revoked then out-of-band mechanisms may be used to replace the revoked certificate. The LwM2M specification does not offer a way to recover from a revoked Bootstrap-Server certificate. Out-of-band mechanism may include replacing the LwM2M Bootstrap-Server certificate via the firmware update mechanism or using a commissioning tool.

5.2.8.7. Certificate Usage Field

The Certificate Usage Resource in the LwM2M Security Object specifies the semantics of the certificate or raw public key stored in the Server Public Key Resource, which is used to match the certificate presented in the TLS/DTLS handshake. RFC 6698 defines for types, which are reused in this specification:

5.2.9. Error Handling

The TLS / DTLS specifications offer ways to report error situations via the Alert protocol. These errors may have multiple reasons and the process to recover from them is essential for a stable LwM2M implementation. Nevertheless recovering from these errors may be challenging since many IoT devices are unattended and a failure in the establishment of a security association may result in a non-functioning device. Since a LwM2M Bootstrap-Server supervises the LwM2M Client it can support with the recovery of certain types of errors, i.e., the LwM2M Client is asked to fall back to the bootstap mode in order to obtain new credentials.

This section provides default recommended error handling. LwM2M Server Object configuration provides additional capabilities via optional resources, such as the Bootstrap on Registration Failure Resource, to define the behavior in error conditions. There is no such fallback mechanism defined for the interaction between the LwM2M Client and the LwM2M Bootstrap-Server.

Table: 5.2.9.-1 TLS/DTLS Error Handling Recommendations
Value Alert Description RFC Recommendation
0 close_notify RFC 5246 Retry
10 unexpected_message RFC 5246 Retry
20 bad_record_mac RFC 5246 Retry
21 decryption_failed RFC 5246 Retry
22 record_overflow RFC 5246 Retry
30 decompression_failure RFC 5246 Ignore*
40 handshake_failure RFC 5246 Retry
41 no_certificate_RESERVED RFC 5246 Ignore*
42 bad_certificate RFC 5246 Fail
43 unsupported_certificate RFC 5246 Fail
44 certificate_revoked RFC 5246 Fail
45 certificate_expired RFC 5246 Fail
46 certificate_unknown RFC 5246 Fail
47 illegal_parameter RFC 5246 Retry
48 unknown_ca RFC 5246 Fail
49 access_denied RFC 5246 Fail
50 decode_error RFC 5246 Retry
51 decrypt_error RFC 5246 Retry
60 export_restriction_RESERVED RFC 5246 Ignore*
70 protocol_version RFC 5246 Retry
71 insufficient_security RFC 5246 Retry
86 internal_error RFC 7507 Retry
90 user_canceled RFC 5246 Retry
100 no_renegotiation RFC 5246 Retry**
110 unsupported_extension RFC 5246 Ignore.
111 certificate_unobtainable RFC 6066 Retry***
112 unrecognized_name RFC 6066 Fail***
113 bad_certificate_status_response RFC 6066 Fail***
114 bad_certificate_hash_value RFC 6066 Fail***
115 unknown_psk_identity RFC 4279 Fail

Legend:

The 'fail' recommendation in the table above indicates that the LwM2M Client MUST consider the handshake exchange failed and that it cannot by itself recover from the error situation. The 'retry' recommendation in the table above indicates that the LwM2M Client MUST consider the handshake failed but that the error situation MAY be transient and retrying the handshake protocol run may result in a successful completion. In both cases the LwM2M Client MUST follow the error handling procedures defined by resources in the LwM2M Server Object, if present.

An implementation may set a limit to the number of attempts to re-establish a TLS/DTLS connection and may decide to fall back to bootstrapping when a certain threshold is exceeded. Implementations should also use an exponential back-off between retransmissions. The number of retries and the retransmission timers MAY be set by resources in the LwM2M Server resources.

Note: Per RFC 6347 DTLS implementations SHOULD silently discard records with bad MACs or that are otherwise invalid.

5.3. Lower- or Higher-Layer Security with the "NoSec" mode

The LwM2M protocol MUST NOT be deployed without appropriate security. Because LwM2M may be deployed with security outside the scope of this specification (e.g. at lower layers), this may mean that neither transport-layer security (TLS/DTLS), nor application-layer security (OSCORE) is applied. In case communication security is not used at the LwM2M layer ("NoSec" mode), the deployment MUST use alternative security mechanisms.

The LwM2M Server MUST compare the endpoint client name identifier used during the Register and the Bootstrap-Request message with the identifier used for network access authentication (typically used to setup link-layer security procedures).

5.4. SMS Channel Security

This section defines the security modes for the transport of CoAP over SMS.

Channel security for [CoAP] has been defined for the UDP transport and is based on DTLS [RFC6347].

LwM2M Clients only supporting the SMS binding MAY support the NoSec mode when the SMS Channel is only used for debugging purposes otherwise they MUST support SMS Secured Mode. In any security mode except for debugging purposes, when an SMS message is received from an MSISDN that is not recorded in the LwM2M Server SMS Number resource of the LwM2M Server Access Security, the SMS message MUST be silently ignored.

LwM2M Clients supporting UDP and SMS bindings, when the SMS binding is only used for triggering, MUST support the adequate mechanism for securing CoAP over UDP. Those clients MAY use any SMS security mode. In particular SMS NoSec mode can be used for SMS triggering since all other communication will be secured by UDP channel security. Note: Using SMS NoSec for SMS triggering could introduce "Denial of Service" (DoS).

The "Secret Key" and "Public Key or Identity" Resources are used to configure the keying material that a Client uses with a particular LwM2M Server. The SMS key parameters are stored in the order KIc, KID, SPI, TAR (KIc is byte 0). Ordering of bits within bytes SHALL follow ETSI TS 102 221, Section 3.4 "Coding Conventions" (b8 MSB, b1 LSB).

5.4.1. SMS "NoSec" Mode

It is RECOMMENDED to always use LwM2M with one of the security mechanisms described in this specification. However, there are few scenarios and use cases where security is provided by lower layers. For example, LwM2M devices in a controlled environment behind a gateway, or, tests focusing first on other functions before performing end-to-end tests including security.

The use of SMS "NoSec" Mode while the Resource "OSCORE Security Mode" is present indicates that the SMS Channel is protected with OSCORE.

This security profile is also useful to support SMS triggering when all other exchanges utilize CoAP over TLS or CoAP over DTLS.

5.4.2. SMS Secured Mode

The SMS Secured mode specified in this section MUST be supported when the SMS binding is used.

A LwM2M Client which uses the SMS binding MUST either be directly provisioned for use with a target LwM2M Server (Factory Bootstrap or Bootstrap from Smartcard) or else be able to bootstrap via the UDP binding.

The end-point for the SMS channel (delivery of mobile terminated SMS, and sending of mobile originated SMS) MAY be either on the Smartcard or on the Device. When the LwM2M Client device doesn’t support a Smartcard, the end-point is on the LwM2M Client device.

A LwM2M Client, Server or Bootstrap-Server supporting SMS binding MUST discard SMS messages which are not correctly protected using the expected parameters stored in the "SMS Binding Key Parameters" Resource and the expected keys stored in the "SMS Binding Secret Keys" Resource, and MUST NOT respond with an error message secured using the correct parameters and keys.

5.4.2.1. Device End-Point

The Secured Packet Structure is based on [3GPP TS 31 115] / [ETSI TS 102 225] which was originally designed for securing packet structures for UICC based applications. However, for LwM2M it is suitable for securing the SMS payload exchanged between client and server. Usage of Secured Packet Structure Packet mode in LwM2M device needs evolution towards the introduction of a secure environment. The intention is to evolve the specifications in the next LwM2M release.

If the SMS channel end-point is on the Device, the Channel security for [CoAP] is based on the Datagram Transport Layer Security (DTLS) [RFC6347]. For that reason the text in Section 5.2. TLS/DTLS-based Security concerning the DTLS binding to CoAP is also applicable to this section.

Appendix A of [RFC7925] describes how to bind CoAP/DTLS message to the SMS channel and specifies the restrictions on DTLS for fitting the SMS channel specific functioning and narrow bandwidth.

5.4.2.1.1. Header Definitions (for one SMS)

a) SMS Frame for basic Request/Response Interaction message (no Token field required)

SMS header definition (no token)
Figure: 5.4.2.1.1.-1 SMS header definition (no token)

Model calculation using these header definitions,

b) SMS Frame for messages of the Information Reporting Interface (Token field required)

SMS header definition
Figure: 5.4.2.1.1.-2 SMS header definition

Model calculation using these header definitions,

5.4.2.1.2. Smartcard End-Point

If the SMS channel end-point is on the smart card, a CoAP message as defined in [CoAP] MUST be encapsulated in [3GPP 31.115] Secured Packets, in implementing - for SMS Point to Point (SMS_PP) - the general [ETSI 102 225] specification for UICC based applications.

The following settings MUST be applied:

Class 2 SMS as specified in [3GPP TS 23.038]. The [3GPP TS 23.040] SMS header MUST be defined as below:

Secure SMS Transfer to UICC

A SMS Secured Packet encapsulating a CoAP request received by the LwM2M device, MUST be – according to [ETSI TS 102 225]/[3GPP TS 31.115] - addressed to the LwM2M UICC Application in the Smartcard where it will be decrypted, aggregated if needed, and checked for integrity.

If decryption and integrity verification succeed, the message contained in the SMS MUST be provided to the LwM2M Client.

If decryption or integrity verification failed, SMS MUST be discarded.

The mechanism for providing the decrypted CoAP Request to the LwM2M Client relies on basic GET_DATA commands of [GP SCP03] .This data MUST follow the format as below:

data_rcv _ ::= <address> <coap_msg>

address ::= TP_OA ; originated address

coap_msg ::= CoAP_TAG <coap_request_length> <coap_request>

coap_request_length ::= 16BITS_VALUE

coap_request ::= CoAP message payload

NOTE: In current LwM2M release, the way the LwM2M Client Application is triggered for retrieving the available message from the Smartcard is device specific: i.e. a middle class LwM2M Device implementing [ETSI TS 102 223] ToolKit with class "e" and "k" support could be automatically triggered by Toolkit mechanisms, whereas a simpler LwM2M device could rely on a polling mechanisms on Smartcard for fetching data when available.

Secured SMS Transfer to LwM2M Server

For sending a CoAP message to the LwM2M Server, the LwM2M Client prepares a data containing the right TP-DA to use, concatenated with the CoAP message and MUST provide that data to the LwM2M UICC Application in using the [GP SCP03] STORE-DATA command.

According to [ETSI TS 102 225] / [3GPP TS 31.115] the Smartcard will be in charge to prepare (encryption / concatenation) the CoAP message before sending it as a SMS Secure Packet ([ETSI TS 102 223] SEND_SMS command).

The SMS Secured Packet MUST be formatted as Secured Data specified in Section 5.4.2.1.3. SMS Secured Packet Binding for CoAP messages.

The Secure Channel as specified in Appendix H of this document SHOULD be used to provide the prepared data to the Smartcard.

5.4.2.1.3. SMS Secured Packet Binding for CoAP messages

In SMS Secured Packet Structure mode, a CoAP message as defined in [CoAP] MUST be encapsulated in [3GPP 31.115] Secured Packets, in implementing - for SMS Point to Point (SMS_PP) - the general [ETSI 102 225] specification for UICC based applications.

5.5. OSCORE-based Security

5.5.1. OSCORE Overview

Object Security for Constrained RESTful Environments [OSCORE] is an application layer security protocol protecting CoAP message exchanges. OSCORE is applicable to protocol messages which can be mapped to CoAP or a subset of CoAP, including HTTP and LwM2M.

The use of OSCORE with LwM2M is optional. It MAY be used for protecting the communication between a LwM2M Client and the LwM2M Bootstrap-Server. It MAY be used between a LwM2M Client and a LwM2M Server.

OSCORE MAY also be used between LwM2M endpoint and non-LwM2M endpoint, e.g. between an Application Server and a LwM2M Client via a LwM2M server. Both the LwM2M endpoint and non-LwM2M endpoint MUST implement OSCORE and be provisioned with an OSCORE Security Context as defined in [OSCORE]. The bootstrapping of the non-LwM2M endpoint is out of scope for this specification. The intermediate LwM2M node needs to map the messages from non-LwM2M nodes to LwM2M operations and responses. That mapping is also out of scope for this specification.

The use of OSCORE in CoAP is indicated with the OSCORE Option present in the CoAP message [OSCORE]. It operates by transforming (encrypting etc.) an unprotected CoAP message into a protected CoAP message using the compact secure message format COSE [RFC8152]. The protected CoAP message is sent instead of the unprotected message, and is verified and transformed back to the original message at the receiving end.

OSCORE protects the Request/Response sublayer of CoAP, but leaves the binding to the transport layer protocol unprotected. As a consequence, OSCORE does not depend on the underlying layer and can therefore be applied to CoAP over UDP, TCP, SMS as well as Non-IP, directly over IEEE 802.15.4 or 3GPP CIoT (see Appendix D). OSCORE is invariant under proxy operations translating between different transport layer protocols, performing application layer forwarding (e.g. CoAP proxies), address translations, etc. and thus enables end-to-end security through these kinds of intermediate nodes.

Not only is OSCORE applicable to CoAP-mappable messages, but the protected messages can also be transported directly in CoAP-mappable protocols. For example, with the HTTP header field "OSCORE" [OSCORE], OSCORE protected messages can be transported in HTTP, providing end-to-end security for CoAP-mappable HTTP. OSCORE also supports proxies translating between HTTP and CoAP as defined in [RFC8075], allowing a mix of HTTP and CoAP along the end-to-end path, which is useful, e.g. for firewall traversals on the Internet.

OSCORE is based on a shared symmetric key and provides security context derivation, encryption, integrity and replay protection, and a secure binding of application layer responses to requests. OSCORE enables mutual authentication between LwM2M Client and LwM2M Bootstrap-Server, and between LwM2M Client and LwM2M Server.

OSCORE is independent of security protocols at other layers, such as DTLS/TLS. If OSCORE is applied with a "Security Mode" Resource value 0-2 (corresponding to DTLS with mode "Pre-Shared Key"/"Raw Public Key"/"Certificate") the message will be protected by both OSCORE and DTLS. When OSCORE is applied with "Security Mode" Resource value 3 (corresponding to DTLS with mode "NoSec"), the message is protected by OSCORE but not DTLS.

OSCORE can be used to secure multicast requests and responses, for example providing low latency in building automation scenarios (lighting, emergency etc.) and for efficient bandwidth usage during firmware updates.

5.5.2. Cryptographic Algorithms

OSCORE is defined for use with an Authenticated Encryption with Additional Data (AEAD) algorithm and a HMAC-based Key Derivation Function (HKDF) [RFC5869]. OSCORE mandates the implementation of the AEAD algorithm AES-CCM-16-64-128 (also known as CCM*) as defined in [RFC8152], and specifies the use of HMAC with SHA-256 as default. LwM2M Clients and LwM2M Servers MAY support additional algorithms that conform to the state-of-the-art security requirements.

5.5.3. Bootstrapping

The OSCORE related Resources in the LwM2M OSCORE Object are used analogously to DTLS/TLS when applied with pre-shared keys (see 5.2.4. Bootstrapping). The OSCORE related Resources in the LwM2M OSCORE Object are used for:

  1. providing OSCORE communication security in "Client Registration", "Device Management & Service Enablement", and "Information Reporting" Interfaces if the LwM2M Security Object Instance relates to a LwM2M Server;

  2. providing OSCORE communication security in the "Bootstrap" Interface if the LwM2M Security Object instance relates to a LwM2M Bootstrap-Server;

  3. providing OSCORE communication security with a firmware repository server when the LwM2M Client receives a URI in the Package URI of the Firmware Update object.

In case of Bootstrap from Smartcard, a secure channel between the Smartcard and the LwM2M Client SHOULD be established, as described in Appendix G and defined in [GLOBALPLATFORM 3], [GP SCP03]. Using Smartcard with the pre-shared key needs no pre-existing trust relationship between LwM2M Server(s) and LwM2M Client(s). The pre-established trust relationship exists between the LwM2M Server(s) and the SmartCard(s).

If OSCORE is used, then LwM2M Clients MUST either be provisioned for use with a LwM2M Server (manufacturer pre-configuration bootstrap mode) or else be provisioned for use with a LwM2M Bootstrap-Server. Any LwM2M Client, which supports client or server initiated bootstrap mode, MUST support bootstrapping with a strong (high-entropy) pre-shared key. The ciphersuites MUST NOT be used with a low-entropy pre-shared key or a password as pre-shared key. The LwM2M Client MUST be provisioned with a pre-shared key that is unique to a device and to the security protocol. For full interoperability a LwM2M Bootstrap-Server MUST support bootstrapping with pre-shared key.

The OSCORE security context is derived from a small set of input parameters (see Section 3.2 of [OSCORE]). With use of the OSCORE input parameters, the security contexts for sending and receiving OSCORE messages are derived as defined in [OSCORE]. The conditions for reuse of input parameters (see Section 3.3 of [OSCORE]) MUST be complied with. An implementation SHALL use a Master Salt as described in Appendix B2 of [OSCORE].

New OSCORE input parameters MAY be provisioned for use between endpoints having an existing OSCORE security context requiring the endpoints to derive new contexts. The Echo option MUST be used by the receiving endpoint when the OSCORE security context is used for the first time (e.g. Bootstrap-Request or Register) and SHOULD be used when the requested operation (e.g. Device Management Write) requires freshness that cannot be guaranteed by other means.

5.5.4. Unbootstrapping

The unbootstrapping procedure described in 5.2.5. Unbootstrapping applies also to OSCORE.

5.5.5. Endpoint Client Name

The same verification of Endpoint Client Name in the Bootstrap-Request and in the Register messages as described in 5.2.6. Endpoint Client Name applies also to OSCORE. However, when using OSCORE, the Endpoint Client Name MAY be authenticated at the application layer, by setting the "OSCORE Sender ID" Resource value (see 5.5.7.1. OSCORE Related Resources) to the Endpoint Client Name.

If the OSCORE Sender ID is not set to Endpoint Client Name, then the LwM2M Server MUST compare the received Endpoint Client Name identifier with the OSCORE Sender ID of the LwM2M Client. This comparison may either be an equality match or may involve a dedicated lookup table to ensure that LwM2M Clients cannot intentionally or due to misconfiguration impersonate other LwM2M Clients. The LwM2M Server MUST respond with a "4.00 Bad Request" to the LwM2M Client if these fields do not match.

5.5.6. OSCORE Roles

The OSCORE roles (Client and Server) coincide with the CoAP roles.

OSCORE specifies that each endpoint has a Sender ID and a Recipient ID. The Sender ID is used when sending a message and recepient ID when receiving a message, independently of whether the endpoint has the role of an OSCORE Client or an OSCORE Server. Hence the Sender ID of the OSCORE Client has the same value as the Recipient ID of the OSCORE Server, and the Recipient ID of the OSCORE Client has the same value as the Sender ID of the OSCORE Server.

5.5.7. Credential Types

OSCORE requires that a shared secret key, called "OSCORE Master Secret", is established in the communicating endpoints. In LwM2M version 1.1 it is assumed that the Master Secret is pre-shared.

When the Master Secret used with a LwM2M Server is provisioned to the LwM2M Client, the Master Secret is also known to the provisioning party, e.g. the LwM2M Bootstrapping Server. Applications need to ensure that this assumption is compliant with their trust model.

The use of OSCORE between LwM2M Client and LwM2M Server, or between LwM2M Client and LwM2M Bootstrap-Server is indicated with the optional "OSCORE Security Mode" Resource in the Security Object description.

The presence of the "OSCORE Security Mode" Resource in a Security Object Instance requires the following resources of the LwM2M OSCORE Object to be populated:

Additionally, the following resources of the LwM2M OSCORE Object MAY be populated:

5.6. Identification of Blockwise Requests

The specification of Blockwise [CoAP_Blockwise] is vulnerable to interchange of blocks between different requests to the same resource [CoAP_ERT]. The attack may be performed when the replay window size of the the security protocol is greater than 1 even if the requests are not inverleaved and the attack applies both to DTLS and OSCORE. The attack does not apply when a connection-oriented transport, like CoAP over TCP is used, or when a replay window size of 1 is selected with DTLS.

A solution is to use the CoAP Request-Tag Option [CoAP_ERT] for unique tagging of requests of a certain scope. The Request-Tag is analogous to the CoAP E-Tag Option, but tags requests instead of responses.

LwM2M Clients and LwM2M Servers supporting Blockwise SHOULD implement the CoAP Request-Tag Option.

5.7. Freshness

A LwM2M Client and LwM2M Server MUST be able to verify the freshness of certain LwM2M operations.

LwM2M operations may have freshness requirements that are not possible to guarantee by protecting individual messages such as with DTLS Record Layer or OSCORE. This is accentuated with unreliable transport. Since datagram transport does not provide reliable or in-order delivery of data, DTLS and OSCORE preserves this property. Although duplicate messages are rejected through the use of anti-replay mechanisms, unordered delivery is still allowed, e.g. using a sliding receive window. As a consequence maliciously delayed message are accepted as long as they fall within the window.

For example, a Write operation, maliciously blocked from reaching the LwM2M Client at one time, may under these circumstances be successfully injected at a later time, potentially overwriting a more recent Write operation.

Operations protected by a security protocol with keys derived from a TLS/DTLS handshake are at least as fresh as the handshake. However, frequent use of the handshake protocols may be prohibitive in constrained environments. In order to avoid unnecessary processing, a more lightweight solution to verify freshness is provided by the CoAP Echo Option [CoAP_ERT], illustrated with the example above: The LwM2M Client, receiving a Write operation of uncertain freshness may respond with an error message containing an Echo option including a random nonce as value. The LwM2M Server receiving the error response to a valid Write operation retransmits the request with the Echo option and value included. The LwM2M Client receiving a request with an Echo option verifies that the nonce corresponds to a recent request, and only in that case performs the operation (for details, see Section 2 of [CoAP_ERT]).

Applications need to understand the freshness requirements of the operations both in LwM2M Client and LwM2M server. The LwM2M implementation SHOULD enable timely freshness verifications to be performed without unnecessary overhead. For interoperability both LwM2M Client and LwM2M Server SHOULD implement the CoAP Echo option.

The attack does not apply when a connection-oriented transport, like CoAP over TCP is used, or when a replay window size of 1 is selected with DTLS.

6. CoAP Transport Binding

This section defines the CoAP transport binding used by LwM2M interfaces.

6.1. Features

The CoAP transport binding utilizes the following features:

6.2. Firewall Traversal

For a firewall to support LwM2M using CoAP over UDP and/or CoAP over DTLS it MUST at a minimum be configured to allow outgoing packets to destination port 5683 (for CoAP over UDP), and port 5684 (for CoAP over DTLS), and allow incoming UDP/DTLS packets back to the source address/port of the outgoing UDP packet for a period of at least 240 seconds.

While Queue Mode is not necessary for firewall configuration it should be noted that LwM2M Clients may enable Queue Mode for example to lower power consumption for a battery powered device.

For those deployments where changes to firewall configurations are not possible CoAP over TCP/TLS SHOULD be used instead. Firewall rule settings for CoAP over TCP/TLS are similar to those described above for CoAP over UDP/DTLS since the port numbers are equivalent, i.e., port 5683 (for CoAP over TCP), and port 5684 (for CoAP over TLS).

6.3. NAT Traversal

A NAT exhibits a behavior similar to a stateful packet filtering firewall where incoming packets are only allowed to traverse the NAT after the client behind the NAT initiated an outgoing connection first. The NAT creates a NAT binding based on the outgoing communication attempt, which is re-used for any packets from the device outside the NAT (i.e., typically the server).

Where NATs are present along the communication path, CoAP over TCP leads to different NAT traversal behavior than CoAP over UDP. NATs often calculate expiration timers based on the transport layer protocol being used by application protocols. Many NATs maintain TCP-based NAT bindings for longer periods based on the assumption that a transport layer protocol, such as TCP, offers additional information about the session lifecycle. UDP, on the other hand, does not provide such information to a NAT and timeouts tend to be much shorter, as described in [CoAP-TCP].

Queue Mode may help with NAT traversal by allowing a LwM2M Server to send messages to the LwM2M Client only after the LwM2M Client has initiated the communication to the LwM2M server first. This ensures that NAT bindings exist that allow incoming packets to the LwM2M Client.

6.4. URI Identifier & Operation Mapping

Although CoAP supports a URI in requests, it is not used in the same way as in HTTP. The URI in CoAP is broken down into binary parts, minimizing overhead and complexity. In LwM2M only path segment and query string URI components are needed. The URI path is used to simply identify the interface, Object Instance or Resource that the request is for, and is encoded in Uri-Path options. The LwM2M Registration interface also makes use of query string parameters to pass on meta-data with the request separately from the payload. Each query parameter is encoded in a Uri-Query Option. Likewise, the LwM2M operations for each interface are mapped to CoAP Methods. All the LwM2M operations using CoAP layer MUST be Confirmable CoAP messages, except as follows:

6.4.1. Alternate Path

By default, the LwM2M Objects are located under the root path. However, devices might be hosting other CoAP Resources on an endpoint, and there may be the need to place LwM2M Objects under an alternate path.

When registering, or updating its registration, a LwM2M Client MAY include an OMA LwM2M link in addition to the Object links in the registration payload. The link is identified by the RFC 6690 [RFC6690] Resource Type parameter "oma.lwm2m".

This link MUST NOT contain numerical URI segment.

For instance, the Example Client from Appendix F may place Objects under the "/lwm2m" path. The registration payload would be as follows:

</lwm2m>;rt="oma.lwm2m", </lwm2m /1/0>,</lwm2m /1/1>,</lwm2m /2/0>,</lwm2m /2/1>,</lwm2m /2/2>,</lwm2m /2/3>,</lwm2m /2/4>,</lwm2m /3/0>,</lwm2m /4/0>,</lwm2m /5>

When using the Device Management & Service Enablement Interface and the Information Reporting Interface, the LwM2M Server MUST prepend the OMA LwM2M link to the path in the CoAP messages. Example: GET /lwm2m/3/0/0.

When using the Bootstrap Interface, the LwM2M Bootstrap-Server MUST use CoAP paths only in the form /{Object ID}/{Object Instance ID}/{Resource ID}. It is the responsibility of the LwM2M Client to map these paths to its alternate path.

The Resource Type value "oma.lwm2m" is part of IANA registry.

6.4.2. Bootstrap Interface

The bootstrap interface is used to optionally configure a LwM2M Client so that it can successfully register with a LwM2M Server. The client bootstrap operation is performed by sending a CoAP POST request to the LwM2M Bootstrap-Server at the "/bs" path including the Endpoint Client Name as a query string parameter. When the bootstrap operation is terminated the Bootstrap-Server MUST send a Bootstrap-Finish indication.

The Client Bootstrap operation is initiated by the LwM2M Client itself. In addition, this operation can be requested by an authorized LwM2M Server executing the "Bootstrap-Request Trigger" Resource of a Server Object Instance, or even by a proprietary mechanism (e.g. based on SMS). Note: the execution of a Bootstrap-Request Trigger Resource by a LwM2M Server in a LwM2M Client is performed through an already established registration and is therefore covered by the access rights mechanisms.

During the Bootstrap Phase, the Client MAY ignore requests and flush all pending responses not related to the Bootstrap sequence.

In "Client Initiated Bootstrap" mode, when the Bootstrap-Server receives Bootstrap-Request operation, the Bootstrap-Server can perform Write, Discover, Read and/or Delete operations. The Delete operation targets an Object or an Object Instance, the Discover operation targets an Object, a Write operation targets Object, Object Instance or a Resource, while the Read operation is limited to read a single Instance or all Instances of the Access Control Object (an error is returned otherwise). The Read, Write, Discover and Delete operations can be sent multiple times. Only in Bootstrap Interface, Delete operation MAY target to "/" URI to delete all the existing Object Instances - except LwM2M Bootstrap-Server Account - in the LwM2M Client, for initialization purpose before LwM2M Bootstrap-Server sends Write operation(s) to the LwM2M Client. Different from "Write" operation in Device Management and Service Enablement interface, the LwM2M Client MUST write the value included in the payload regardless of an existence of the targeting Object Instance(s) or Resource and access rights.

Only in Bootstrap Interface, the Discover command MAY target to "/" URI to discover all Objects and Object Instances supported in the Device.

The Bootstrap-Server MUST send finish indication after it has sent all object instances/resources. Bootstrap-Server sends finish message by sending CoAP POST to "/bs" location path with empty payload.

If OSCORE is used to secure Client Bootstrap then the Bootstrap-Server receiving the Bootstrap-Request operation MUST use the Echo Option [CoAP_ERT].

Table: 6.4.2.-1 Operation to Method and URI Mapping (Bootstrap Interface)
Operation CoAP Method URI Success Failure
Bootstrap-Request POST /bs?ep={Endpoint Client Name}&pct={Preferred Content Format} 2.04 Changed 4.00 Bad Request, 4.15 Unsupported content format
Read GET Accept:Content Format ID: TLV, CBOR or JSON /{Object ID} in LwM2M 1.1 Object ID MUST be '2' (Access Control Object) 2.05 Content 4.00 Bad Request, 4.01 Unauthorized, 4.04 Not Found, 4.05 Method not Allowed, 4.06 Not Acceptable
Write PUT /{Object ID}/{Object Instance ID}/{Resource ID} 2.04 Changed 4.00 Bad Request
Delete DELETE /{Object ID}/{Object Instance ID} 2.02 Deleted 4.00 Bad Request
Discover GET Accept: application/link-format /{Object ID} 2.05 Content 4.00 Bad Request, 4.04 Not Found
Bootstrap-Finish POST /bs 2.04 Changed 4.00 Bad Request, 4.06 Not Acceptable
Example of Client initiated Bootstrap exchange
Figure: 6.4.2.-1 Example of Client initiated Bootstrap exchange
Example of Server initiated Bootstrap exchange
Figure: 6.4.2.-2 Example of Server initiated Bootstrap exchange

6.4.3. Registration Interface

The registration interface is used by a LwM2M Client to register with a LwM2M Server, identified by the LwM2M Server URI.

Registration is performed by sending a CoAP POST to the LwM2M Server URI /rd, with registration parameters passed as query string parameters as per Table: 6.4.3.-1 Operation to Method and URI Mapping (Registration Interface) and Object and Object Instances included in the payload as specified in [LwM2M-CORE]. The response includes Location-Path Options, which indicate the path to use for updating or deleting the registration. The LwM2M Server MUST return a location under the /rd path segment.

As the network connectivity may be limited or intermittent, it is advised to make several retries of the Registration if no reply is received from the LwM2M Server before considering the registration as failed.

When a new TLS/DTLS handshake is started, or in NoSec mode when the LwM2M Client IP address changes, the Client MUST register again to the LwM2M Server.

If OSCORE is used to secure the Registration then the Echo Option [CoAP_ERT] MUST at least be used with the first operation.

Registration update is performed by sending a CoAP POST to the Location path returned to the LwM2M Client as a result of a successful registration.

De-registration is performed by sending a CoAP DELETE to the Location path returned to the LwM2M Client as a result of a successful registration.

Table: 6.4.3.-1 Operation to Method and URI Mapping (Registration Interface)
Operation CoAP Method URI Success Failure
Register POST /rd?ep={Endpoint Client Name}&lt={Lifetime}&lwm2m={version}&b={binding}&Q&sms={MSISDN} 2.01 Created 4.00 Bad Request, 4.03 Forbidden, 4.12 Precondition Failed
Update POST /{location}?lt={Lifetime}&b={binding}&Q&sms={MSISDN} 2.04 Changed 4.00 Bad Request, 4.04 Not Found
De-register DELETE /{location} 2.02 Deleted 4.00 Bad Request, 4.04 Not Found

Note: Throughout the present document the format of the MSISDN must be as specified in [3GPP-TS_23.003]. According to this definition "+" is not preceding the country code.

Example register, update and de-register operation exchanges (shorthand in \[CoAP\] example style, actual messages using CoAP binary headers
Figure: 6.4.3.-1 Example register, update and de-register operation exchanges (shorthand in \[CoAP\] example style, actual messages using CoAP binary headers

6.4.4. Device Management & Service Enablement Interface

The Device Management & Service Enablement Interface is used to access a Resource, a Resource Instance, an array of Resource Instances, an Object Instance or all the Object Instances of an Object. An Object Instance is identified by the path /{Object ID}/{Object Instance ID}. If Object doesn't support multiple Object Instances, the Object Instance is identified by the path /{Object ID}/0. A Resource is identified by the path /{Object ID}/{Object Instance ID}/{Resource ID}. An Instance of a Multiple-Instance Resource is identified by the path /{Object ID}/{Object Instance ID}/{Resource ID}/{Resource Instance ID}. When the rules expressed in [LwM2M-CORE] and related to the path in the command on this LwM2M Interface, are not respected, the error code 4.05 MUST be returned as response code.

An Object Instance, a Resource or a Resource Instance are read by sending a CoAP GET to the corresponding path. The response includes the value in the corresponding format according to the specified Content-Format (see [LwM2M-CORE]).The request MAY specify an Accept option containing the preferred Content-Format to receive. When the specified Content-Format is not supported by the LwM2M Client, the request MUST be rejected (error code 4.06).

Note that the response payload may be empty, for instance when performing a Read operation on an Object with no Object Instance. In this case the response code is still 2.05 Content.

An Object Instance, a Resource or a Resource Instance are written by sending a CoAP PUT request to the corresponding path. The request includes the value to be written in the corresponding Plain Text, Opaque, TLV, CBOR or JSON format according to the Content-Format option which MUST be specified [CoAP]. In addition, an Object Instance can be written by sending a CoAP POST request; in that case the specified Content-Format MUST be one of the TLV, CBOR or JSON formats. A CoAP PUT is used for the Replace and CoAP POST is used for Partial Update mechanism of the "Write" operation as described in [LwM2M-CORE].

The Write request MUST be rejected :

A Resource is Executed by sending a CoAP POST to the corresponding path. The request MAY include a list of arguments as value of the payload expressed in Plain Text format. The definition of the Executable Resource and its arguments as described in Appendix D of [LwM2M-CORE].

The list of arguments can be empty, have one argument, or have multiple arguments. Multiple arguments are separated by a comma. The syntax of the arguments is provided in [LwM2M-CORE].

Note that the behaviour of the "Execute" operation, whether it uses arguments and how those are interpreted, and how it returns values, is specified in the Resource description of the Object.

An Object Instance is Created by sending a CoAP POST to the corresponding path. The request includes the value to be written in the corresponding TLV, CBOR or JSON format according to the Content-Format option which MUST be specified. The rules governing the creation of Resources in the targeted Object Instance are specified in [LwM2M-CORE]. If Object Instance is not listed at the request, the LwM2M Client MUST assign ID of that Object Instance and send back Object Instance ID with "2.01 Created" to the LwM2M Server when Object Instance is Created.

An Object Instance is Deleted by sending a CoAP DELETE to the corresponding path.

When a Resource supports multiple instances, the Resource value is an array of Resource Instances.

<NOTIFICATION> Class Attributes MAY be set by a LwM2M Server using the "Write-Attributes" operation by sending a CoAP PUT on the corresponding path, and can be accessed using the "Discover" operation. The Discover operation (uses a CoAP GET on the corresponding path along with the application/link-format Content type, to retrieve a list of Objects, Object Instances, Resources and their attached or assigned attributes, from the LwM2M Client (see [LwM2M-CORE] for more details on DISCOVER command). With the "Write-Attributes" operation one or more Attributes can be written at a time. When several Attributes are specified in the same "Write-Attributes" command, they MUST be consistent according to the rules defined in [LwM2M-CORE], otherwise the "Write-Attributes" command MUST be rejected (4.00 Bad Request).The values of these Attributes are used by the Information Reporting interface to determine how often Notifications are sent regarding that Resource. A LwM2M Client MAY support a separate set of configured Attributes for each individual LwM2M Server.

A "Write-Attributes" command specifies which value is set to which Attribute and at which level (Object / Object Instance / Resource / Resource Instance). In a similar way, the same command without value for the specified Attribute, MUST be used to unset this Attribute for the given level; then the precedence rules applies when notification occurs (see [LwM2M-CORE]).

As example:

  1. Write-Attributes /3/0/9?pmin=1 means the Battery Level value will be notified to the Server with a minimum interval of 1sec; this value is set at the Resource level.

  2. Write-Attributes /3/0/9?pmin means the Battery Level will be notified to the Server with a minimum value (pmin) given by the default one (resource 2 of Object Server ID=1), or with another value if this Attribute has been set at another level (Object or Object Instance: see [LwM2M-CORE]).

  3. Write-Attributes /3/0?pmin=10 means that all Resources of Object Instance 0 of the Object ‘Device (ID:3)' will be notified to the Server with a minimum interval of 10 sec; this value is set at the Object Instance level.

  4. Write-Attributes /3/0/9?gt=45&st=10 means the Battery Level will be notified to the Server when:

    1. old value is 45 and new value is 50 due to gt condition

    2. old value is 38 and new value is 49 due to both gt and step conditions

Note: if old value is 48 and new value is 42, it is not considered as satisfying any condition.

  1. Write-Attributes /3/0/9?lt=20&gt=85&st=10 means the Battery Level will be notified to the Server when:

    1. old value is 75 and new value is 90 due to both gt and step conditions

    2. old value is 50 and new value is 10 due to both lt and step conditions

    3. old value is 87 and new value is 99 due to step condition

Note: if old value is 17 and new value is 24, this is not considered for any action by the client as no condition is satisfied

The value for an Object, an Object Instance, a Resource or a Resource Instance can also be sent by a LwM2M Client in an unsolicited manner to the LwM2M Server by using the "Send" command. That command is carried out by sending a CoAP POST request to a predetermined path on the LwM2M Server. That path is /dp, standing for "data push". The "Content-Format" CoAP option (header) MUST be set to inform the LwM2M Server of the format of the payload sent in that CoAP POST request. The content format MUST be either JSON or CBOR format described in [LwM2M-CORE].

As example:

Reporting the location of the LwM2M Client and the radio signal strength:

CoAP POST Uri-Path:"dp" Content-Format:application/senml+json
Payload:
[
  {"n":"/6/0/0", "v":43.61092},
  {"n":"/6/0/1", "v":3.87723},
  {"n":"/4/0/2", "v":-49}
]
Table: 6.4.4.-1 Operation to Method and URI Mapping (Device Management & Service Enablement Interface)
Operation CoAP Method and Content Formats Path Success Failure
Read GET
Accept: see [LwM2M-CORE]
/{Object ID}/{Object Instance ID}/{Resource ID}/{Resource Instance ID} 2.05 Content 4.00 Bad Request, 4.01 Unauthorized, 4.04 Not Found, 4.05 Method Not Allowed, 4.06 Not Acceptable
Read-Composite FETCH
Content Format: CBOR or JSON
Accept: CBOR or JSON (see [LwM2M-CORE])
URI paths are provided in request payload 2.05 Content 4.00 Bad Request, 4.01 Unauthorized, 4.04 Not Found, 4.05 Method Not Allowed, 4.06 Not Acceptable, 4.15 Unsupported Content-Format
Discover GET
Accept: application/link-format
/{Object ID}/{Object Instance ID}/{Resource ID} 2.05 Content 4.00 Bad Request, 4.04 Not Found, 4.01 Unauthorized, 4.05 Method Not Allowed
Write PUT or POST
Content Format: see [LwM2M-CORE]
/{Object ID}/{Object Instance ID}/{Resource ID}/{Resource Instance ID}
/{Object ID}/{Object Instance ID}
2.04 Changed, 2.31* Continue 4.00 Bad Request, 4.04 Not Found, 4.01 Unauthorized, 4.05 Method Not Allowed, 4.06 Not Acceptable, 4.08* Request Entity Incomplete, 4.13* Request entity too large
Write-Attributes PUT /{Object ID}/{Object Instance ID}/{Resource ID}/{Resource Instance ID}?pmin={minimum period}&pmax={maximum period}&gt={greater than}&lt={less than}&st={step}&epmin={minimum evaluation period}&epmax={maximum evaluation period} 2.04 Changed 4.00 Bad Request, 4.04 Not Found, 4.01 Unauthorized, 4.05 Method Not Allowed
Write-Composite iPATCH
Content Format: CBOR or JSON (see [LwM2M-CORE])
URI path and a new value for each of resource to be written to is provided in request payload 2.04 Changed 4.00 Bad Request, 4.01 Unauthorized, 4.04 Not Found, 4.05 Method Not Allowed, 4.06 Not Acceptable
Execute POST
Content Format: text/plain or none
/{Object ID}/{Object Instance ID}/{Resource ID} 2.04 Changed 4.00 Bad Request, 4.01 Unauthorized, 4.04 Not Found, 4.05 Method Not Allowed
Create POST
Content Format: CBOR, JSON, or TLV (see [LwM2M-CORE])
/{Object ID} 2.01 Created 4.00 Bad Request, 4.01 Unauthorized, 4.04 Not Found, 4.05 Method Not Allowed, 4.06 Not Acceptable
Delete DELETE /{Object ID}/{Object Instance ID} 2.02 Deleted 4.00 Bad Request, 4.01 Unauthorized, 4.04 Not Found, 4.05 Method Not Allowed
Send POST
Content Format: CBOR or JSON (See [LwM2M-CORE])
/dp 2.04 Changed 4.00 Bad Request, 4.04 Not Found
Example of Device Management & Service Enablement interface exchanges
Figure: 6.4.4.-1 Example of Device Management & Service Enablement interface exchanges
Example of Object Creation and Deletion
Figure: 6.4.4.-2 Example of Object Creation and Deletion

6.4.5. Information Reporting Interface

Periodic and event-triggered reporting about Resource values from the LwM2M Client to the LwM2M Server is achieved through CoAP Observation [OBSERVE]. This simple mechanism allows the LwM2M Server to send a GET request with Observe option =0 for an Object, Object Instance, Resource or Resource Instance which results in asynchronous notifications whenever that Object Instance changes (periodically or as a result of an event). Token of CoAP layer is used to match the asynchronous notifications with the Observe GET. The LwM2M Server can cancel the "Observe" operation by sending Reset message as the response for Notify message in which the LwM2M Server is not interested any more. When the LwM2M Client receives a Reset in response of a "Notify" operation, the LwM2M Client MUST cancel the Observation regardless if the Notify was sent as a confirmable CoAP message as defined in [OBSERVE] or as a non-confirmable CoAP message. The LwM2M Server can also cancel the "Observe" operation at any moment, on a specified Resource, Resource Instance or specified Object Instance(s), by sending a GET request with Observe option=1. The LwM2M Server may set the Observe attributes of a Resource to affect the behavior of its notifications using the "Write-Attributes" operation (see [LwM2M-CORE]).

Table: 6.4.5.-1 Operation to Method and URI Mapping (Information Reporting Interface)
Operation CoAP Method Path Success Failure
Observe GET with Observe option = 0 /{Object ID}/{Object Instance ID}/{Resource ID}/{Resource Instance ID} 2.05 Content with Observe option 4.00 Bad Request, 4.04 Not Found, 4.01 Unauthorized, 4.05 Method Not Allowed
Observe-Composite FETCH with Observe option = 0, Content Format ID: CBOR or JSON, Accept: Content Format ID: CBOR or JSON (see [LwM2M-CORE]) URI paths for resources to be observed are provided in request payload 2.05 Content with Observe option 4.00 Bad Request, 4.04 Not Found, 4.01 Unauthorized, 4.05 Method Not Allowed, 4.15 Unsupported Content-Format
Cancel Observation GET with Observe option= 1 /{Object ID}/{Object Instance ID}/{Resource ID}/{Resource Instance ID} 2.05 Content without Observe option 4.00 Bad Request, 4.04 Not Found, 4.01 Unauthorized, 4.05 Method Not Allowed
Cancel Observation-Composite FETCH with Observe option= 1 URI paths for exactly the same resources listed in the "Observe-Composite" operation that is being canceled are provided in request payload 2.05 Content without Observe option 4.00 Bad Request, 4.04 Not Found, 4.01 Unauthorized, 4.05 Method Not Allowed
Notify Asynchronous Response 2.05 Content with Values
Example of an Information Reporting exchange
Figure: 6.4.5.-1 Example of an Information Reporting exchange

6.5. Queue Mode Operation

The LwM2M Server MUST support Queue Mode and the LwM2M Client SHOULD support Queue Mode.

The LwM2M Client indicates support of Queue Mode in the registration to the LwM2M Server. When the LwM2M Client is not online, the LwM2M Server does not immediately send downlink requests, but instead waits until the LwM2M Client is online. As such, the Queue Mode offers functionality for a LwM2M Client to inform the LwM2M Server that it may be disconnected for an extended period of time. The LwM2M Server uses this information to adjust timers and relay messages from and to the LwM2M Client accordingly.

The LwM2M Client lets the LwM2M Server know it is awake by sending a registration update message as a Confirmable message. Absent any application specific profiles, it is RECOMMENDED that the LwM2M Client waits at least MAX_TRANSMIT_WAIT seconds [CoAP] from the last CoAP message it sent to the LwM2M Server before intentionally going offline.

In order to find out whether a message was successfully delivered from the LwM2M server to the LwM2M client the LwM2M server has to rely on a response. This response tells the server that the message has been received and processed (regardless of what the result of the processing was). A response can be conveyed to the server in two ways:

If message delivery fails, for example, because the message got lost due to network connectivity issues or because the LMW2M Client was sleeping then CoAP re-transmission behaviour at the LwM2M Server will try to retransmit the message. The CoAP stack at the LwM2M Server will resend the message up to a certain number of attempts, as described in Section 4.2 of [CoAP]. If these retransmission attempts fail, the CoAP stack at the LwM2M Server will give up and inform the LwM2M layer. The LwM2M Server has to inform the application about this failed delivery but this API is outside the scope of the LwM2M specification.

Due to the congestion control approach used by CoAP the LwM2M Server has to wait for a response to a request before sending out the next request from the queue since [CoAP] limits the number of simultaneous outstanding interactions to 1.

Despite the title of the functionality, i.e. Queue Mode, this specification does not mandate an implementation to use queues nor does it specify where such a queue would exist (or any details of such queuing mechanism).

A typical Queue Mode sequence follows the following steps:

  1. The LwM2M Client registers to the LwM2M Server and requests the LwM2M Server to run in Queue mode by using the correct Binding value in the registration.

  2. The LwM2M Client is recommended to use the CoAP MAX_TRANSMIT_WAIT parameter to set a timer for how long it shall stay awake since last sent message to the LwM2M Server. After MAX_TRANSMIT_WAIT seconds without any messages from the LwM2M Server, the LwM2M Client enters a sleep mode.

  3. At some point in time the LwM2M Client wakes up again and transmits a registration update message. Note: During the time the LwM2M Client has been sleeping the IP address assigned to it may have been released and / or existing NAT bindings may have been released. If this is the case, then the client needs to re-run the TLS/DTLS handshake with the LwM2M Server since an IP address and/or port number change will destroy the existing security context. For performance and efficiency reasons it is RECOMMENDED to utilize the TLS/DTLS session resumption.

  4. When the LwM2M Server receives a message from the Client, it determines whether any messages need to be sent to the LwM2M Client, as instructed by the application server.

Below is an example flow for Queue Mode in relation to Device Management & Service Enablement Interface.

Example of Device Management & Service Enablement interface exchanges for Queue Mode
Figure: 6.5.-1 Example of Device Management & Service Enablement interface exchanges for Queue Mode

Below is an example flow for Queue Mode in relation to Information Reporting Interface

Example of an Information Reporting exchange for Queue Mode
Figure: 6.5.-2 Example of an Information Reporting exchange for Queue Mode

6.6. SMS Registration Update Trigger Mechanism

When the LwM2M Client has registered to a LwM2M Server, the LwM2M Server can make the LwM2M Client update its registration by executing the Registration Update Trigger Resource in the matching Server Object Instance (see [LwM2M-CORE] Appendix).

When the LwM2M Client has registered with a Current Transport Binding different than "S", if the Trigger Resource in the matching Server Object Instance exists and is true, the LwM2M Server MAY send this trigger message over SMS. The LwM2M Client informs the LwM2M Server of its capability to receive trigger messages over SMS by including the SMS Number parameter in its registration message as defined in [LwM2M-CORE].

Below is an example flow to trigger the LwM2M Client in Queue Mode to send Update message to the LwM2M Server regardless of expiration of Lifetime. Post /1/x/8 would bring the LwM2M Client online to connect to the LwM2M server, where "x" represents the right instance pointing to the server. Optionally, a transport can be included in the Registration Update Trigger. Upon receiving POST /1/x/8?0=U, the LwM2M Client MAY use this transport binding to reconnect with the LwM2M Server. In this example, U refers to the UDP Binding. The possible values for binding Resource is listed in 5.3.1.1.

Example of Device Management & Service Enablement interface exchanges for Queue Mode with SMS Registration Update Trigger
Figure: 6.6.-1 Example of Device Management & Service Enablement interface exchanges for Queue Mode with SMS Registration Update Trigger
### Response Codes

This section lists available response codes of each operation. The codes are divided into each interface. These are the only valid response codes defined in for the LwM2M Enabler.

Table: 6.6.-1 Response Codes: Bootstrap Interface
Operations Available CoAP Response Codes Reason Phrase
Bootstrap-Request 2.04 Changed Bootstrap-Request is completed successfully
4.00 Bad Request Unknown Endpoint Client Name
Read 2.05 Content "Read" operation is completed successfully
4.00 Bad Request Undetermined error occurred
4.01 Unauthorized Access Right Permission Denied
4.04 Not Found URI of "Read" operation is not found
4.05 Method Not Allowed Target is not allowed for "Read" operation
4.06 Not Acceptable None of the preferred Content-Formats can be returned
Write 2.04 Changed "Write" operation is completed successfully
4.00 Bad Request The format of data to be written is different
4.15 Unsupported content format The specified format is not supported
Discover 2.05 Content "Discover" operation is completed successfully
4.00 Bad Request Undetermined error occurred
4.04 Not Found URI of "Discover" operation is not found
Delete 2.02 Deleted "Delete" operation is completed successfully
4.00 Bad Request Bad or unknown URI provided
Bootstrap-Finish 2.04 Changed Bootstrap-Finished is completed successfully
4.00 Bad Request Bad URI provided
4.06 Not Acceptable Inconsistent loaded configuration
Table: 6.6.-2 Response Codes: Client Registration Interface
Operations Available CoAP Response Codes Reason Phrase
Register 2.01 Created "Register" operation is completed successfully
4.00 Bad Request The mandatory parameter is not specified or unknown parameter is specified
Unknown Endpoint Client Name
Endpoint Client Name does not match with CN field of X.509 Certificates
4.03 Forbidden The Endpoint Client Name registration in the LwM2M Server is not allowed.
4.09 Conflict The Client registration conflicts with the LwM2M Server's configuration.
4.12 Precondition Failed Supported LwM2M Versions of the Server and the Client are not compatible
Update 2.04 Changed "Update" operation is completed successfully
4.00 Bad Request The mandatory parameter is not specified or unknown parameter is specified
4.04 Not Found URI of "Update" operation is not found
De-register 2.02 Deleted "De-register" operation is completed successfully
4.00 Bad Request Undetermined error occurred
4.04 Not Found URI of "De-register" operation is not found
Table: 6.6.-3 Response Codes: Device Management and Service Enablement Interface
Operations Available CoAP Response Codes Reason Phrase
Create 2.01 Created "Create" operation is completed successfully
4.00 Bad Request Target (i.e., Object) already exists
Mandatory Resources are not specified
Content Format is not specified
4.01 Unauthorized Access Right Permission Denied
4.04 Not Found URI of "Create" operation is not found
4.05 Method Not Allowed Target is not allowed for "Create" operation
4.15 Unsupported content format The specified format is not supported
Read 2.05 Content "Read" operation is completed successfully
4.00 Bad Request Undetermined error occurred
4.01 Unauthorized Access Right Permission Denied
4.04 Not Found URI of "Read" operation is not found
4.05 Method Not Allowed Target is not allowed for "Read" operation
4.06 Not Acceptable None of the preferred Content-Formats can be returned
Write 2.04 Changed "Write" operation is completed successfully
2.31 Continue
4.00 Bad Request The format of data to be written is different
4.01 Unauthorized Access Right Permission Denied
4.04 Not Found URI of "Write" operation is not found
4.05 Method Not Allowed Target is not allowed for "Write" operation
4.08 Request Entity Incomplete
4.13 Request entity too large
4.15 Unsupported content format The specified format is not supported
Delete 2.02 Deleted "Delete" operation is completed successfully
4.00 Bad Request Undetermined error occurred
4.01 Unauthorized Access Right Permission Denied
4.04 Not Found URI of "Delete" operation is not found
4.05 Method Not Allowed Target is not allowed for "Delete" operation
Execute 2.04 Changed "Execute" operation is completed successfully
4.00 Bad Request The LwM2M Server doesn‟t understand the argument in the payload
4.01 Unauthorized Access Right Permission Denied
4.04 Not Found URI of "Execute" operation is not found
4.05 Method Not Allowed Target is not allowed for "Execute" operation
Write-Attributes 2.04 Changed "Write-Attributes" operation is completed successfully
4.00 Bad Request The format of attribute to be written is different
4.01 Unauthorized Access Right Permission Denied
4.04 Not Found URI of "Write-Attributes" operation is not found
4.05 Method Not Allowed Target is not allowed for Write-Attributes operation
Discover 2.05 Content "Discover" operation is completed successfully
4.00 Bad Request Undetermined error occurred
4.01 Unauthorized Access Right Permission Denied
4.04 Not Found URI of "Discover" operation is not found
4.05 Method Not Allowed Target is not allowed for Discover operation
Send 2.04 Changed "Send" operation completed successfully
4.00 Bad Request Undetermined error occurred
4.04 Not Found Reported Object was not registered to the LwM2M Server
Table: 6.6.-4 Response Codes: Information Reporting Interface
Operations Available CoAP Response Codes Reason Phrase
Observe
Cancel Observe
2.05 Content Operation is completed successfully
4.00 Bad Request Undetermined error occurred
4.01 Unauthorized Access Right Permission Denied
4.04 Not Found URI of Operation is not found or not supported
4.05 Method Not Allowed Target is not allowed for the Operation
4.06 Not Acceptable None of the preferred Content-Formats can be returned
Notify 2.05 Content "Notify" operation is completed successfully

If any operation in Table 2 to Figure 8 cannot be completed in the client and the reason cannot be described by a more specific response code, then a generic response code of "5.00 Internal Server Error" MUST be returned.

6.7. CoAP Transport Bindings

The LwM2M Server and the LwM2M Client MUST support the UDP binding, specified in Section 6.7.1. UDP Binding, and the LwM2M Server SHOULD support the SMS binding specified in Section 6.7.3. SMS Binding. The LwM2M Client MAY support other bindings defined in this specification.

6.7.1. UDP Binding

The CoAP binding for UDP is defined in [CoAP]. The protocol has an IANA registered scheme of coap:// and a default port of 5683. The UDP binding is used in NoSec (no security) mode. The CoAP binding for DTLS is defined in [CoAP]. The URI scheme is coaps:// and the default port is 5684.

Reliability of CoAP messages over the DTLS transport is provided by the built-in retransmission mechanism of CoAP.

6.7.2. TCP Binding

The CoAP binding for TCP is defined in [CoAP_TCP]. The protocol has an IANA registered scheme of coap+tcp:// and a default port of 5683. The TCP binding is used in NoSec (no security) mode. The CoAP binding for TLS is defined in [CoAP_TCP]. The URI scheme for CoAP over TLS is coaps+tcp:// and the default port is 5684.

6.7.3. SMS Binding

CoAP is used over SMS in this transport binding by placing a CoAP message in the SMS payload using 8-bit encoding. SMS concatenation MAY be used for messages larger than 140 characters. CoAP retransmission is disabled for this binding. A LwM2M Client indicates the use of this binding by including a parameter ("sms") in its registration to the LwM2M Server including the node's MSISDN number.

6.7.4. LoRaWAN Binding

When using LwM2M over LoRaWAN, the LoRaWAN Endpoint MUST be the LwM2M Client. The LwM2M Server and the LwM2M Bootstrap-Server MUST be LoRaWAN Application Servers as defined by [LoRaWAN].

The LoRaWAN binding is used in NoSec (no security) mode. Security is provided by the LoRaWAN transport.

The Server URI MUST be in the form "lorawan://{port}", port being the FPort between 1 and 255 as defined in [LoRaWAN].

Due the limited bandwidth of the LoRaWAN transport, the "register" operation has different parameter requirements on this transport.

Table: 6.7.4.-1 LoRaWAN binding registration parameters
Parameter Required Default Value Notes
Endpoint Client Name No DevEUI This parameter is omitted if the endpoint name is identical to the endpoint DevEUI
Lifetime No 2 592 000 (30 days)
LwM2M Version No 1.1 This parameter is omitted if the LwM2M enabler version is 1.1
Binding Mode No By nature, the LoRaWAN network is equivalent to Queue Mode.
SMS Number No The value of this parameter is the MSISDN where the LwM2M Client can be reached for use with the SMS binding.
Objects and Object Instances No The list of Objects supported and Object Instances available on the LwM2M Client (Security Object ID:0 MUST not be part of this list).

The Objects and Object Instances list MAY be omitted in the first registration attempt. If the LwM2M Server can not retrieve this list by out-of-band means (e.g. preconfiguration of the endpoint on the Application Server), it MUST reply to the registration message with a 4.09 (Conflict) code. In this case, the LwM2M Client SHOULD retry to register with a registration message that MUST include the Objects and Object Instances list.

CoAP is used over LoRaWAN in this transport binding by placing a CoAP message in the LoRaWAN packet payload. Piggybacked responses MUST be used.

Due to the high latency of the LoRaWAN network, its asymmetric nature and the intermittent availability of the LoRaWAN endpoints, CoAP retransmission is disabled for this binding and is replaced by the logic defined in Appendix CoAP over LoRaWAN (Normative).

6.7.5. CIoT Binding

CoAP can be used over 3GPP CIoT [3GPP-TR_23.720] as part of IP and non-IP data transmissions over User Plane and Control Plane. This is described in more detail in Appendix D.

Appendix A. Change History (Informative)

A.1 Approved Version 1.1 History

Table: A.1-1 Approved Version 1.1 History
Reference Date Description
n/a n/a No prior version

Appendix B. Static Conformance Requirements (Normative)

Static Conformance Requirements are addressed in the LwM2M ETS.

Appendix C. CoAP over LoRaWAN (Normative)

This appendix defines the retransmission logic of CoAP CON messages over a LoRaWAN network.

C.1 LoRaWAN overview

A LoRaWAN network is composed of Endpoints communicating with Application Servers throught a Network Server. The role of the Network Server is to dispatch messages from the Endpoints to the revelant Application Server and to buffer messages from the Application Server to the Endpoint until the Endpoint is available for reception. A "Class A" Endpoint can receive messages only during RX windows opened after transmitting a message. "Class B"and "Class C" Endpoints are able to receive at specified periodicity. As LoRaWAN uses frequency in an unlicensed spectrum, Endpoints must respect a duty cycle which varies from region to region.

A LoRaWAN network features two kind of messages:

C.2 Configuration

MAX_RETRANSMIT is set to 4.

ACK_TIMEOUT is set to 300 seconds.

C.3 Retransmission logic

C.3.1 Using LoRaWAN confirmable messages

C.3.1.1 Requests originating from the Endpoint
  1. The Endpoint sends a CoAP CON message. If the matching CoAP ACK or RST is received during its RX windows, the exchange is successful.
  2. Otherwise, when the Endpoint is available, it opens a RX window by sending a LoRaWAN packet. If the Endpoint has no data scheduled for transmission, it sends a CoAP Empty message instead.

The Endpoint repeats step 2. MAX_RETRANSMIT times until the matching CoAP ACK or RST is received.

The LwM2M Server MUST reply to CoAP CON messages as soon as possible.

Example of CoAP request from Endpoint using LoRaWAN confirmable messages
Figure: C.3.1.1-1 Example of CoAP request from Endpoint using LoRaWAN confirmable messages
C.3.1.2 Requests originating from the Application Server
  1. The Application Server sends a CoAP CON message.
  2. The Network Server notifies the Application Server when the CoAP message was sent to the Endpoint or when the sending failed.
  3. If the sending was successful, the Application server waits for the CoAP ACK or RST message from the Endpoint.
Example of CoAP request from Application Server using LoRaWAN confirmable messages
Figure: C.3.1.2-1 Example of CoAP request from Application Server using LoRaWAN confirmable messages

C.3.2 Using LoRaWAN unconfirmable messages

C.3.2.1 Requests originating from the Endpoint
  1. The Endpoint sends a CoAP CON message. If the matching CoAP ACK or RST is received during its RX windows, the exchange is successful.
  2. Otherwise, when the Endpoint is available, it opens a RX window by sending a LoRaWAN packet. If the Endpoint has no data scheduled for transmission, it sends a CoAP Empty message instead. If the matching CoAP ACK or RST is received during its RX windows, the exchange is successful.
  3. Otherwise, when the Endpoint is available, it resends the initial CoAP CON message. If the matching CoAP ACK or RST is received during its RX windows, the exchange is successful.

The Endpoint repeats steps 2. and 3. MAX_RETRANSMIT times until the matching CoAP ACK or RST is received.

The Application Server MUST reply to CoAP CON messages as soon as possible.

Example of CoAP request from Endpoint using LoRaWAN unconfirmable messages
Figure: C.3.2.1-1 Example of CoAP request from Endpoint using LoRaWAN unconfirmable messages
C.3.2.2 Requests originating from the Application Server
  1. The Application Server sends a CoAP CON message.
  2. When the Network Server notifies the Application Server that the CoAP message was sent to the Endpoint, the Application Server waits for the CoAP ACK or RST message from the Endpoint during ACK_TIMEOUT seconds.
  3. If the CoAP ACK or RST message was not received after ACK_TIMEOUT seconds, the Application Server resends the initial CoAP CON message.

The Application Server repeats steps 2. and 3. MAX_RETRANSMIT times until the matching CoAP ACK or RST is received.

When receiving a CoAP CON message in an unconfirmable LoRaWAN packet, the Endpoint MUST reply in the ACK_TIMEOUT timeframe.

Example of CoAP request from Application Server using LoRaWAN unconfirmable messages
Figure: C.3.2.2-1 Example of CoAP request from Application Server using LoRaWAN unconfirmable messages

Appendix D. LwM2M over 3GPP CIoT - NB-IoT and LTE-M

D.1 Introduction

Note: The 3GPP vocabulary and abbreviations used in the Annex are explained in [3GPP-TR_21.905].

3GPP has specified Narrow-Band IoT (NB-IoT) and eMTC enhancements (aka. LTE Cat M1), as part of their Release 13. NB-IoT and CAT-M1 includes solutions for support of infrequent data transmission via user plane and via control plane. The user plane solution includes IP data and SMS support. The control plane solution includes IP data, non-IP data and SMS support. The main focus of this annex is on considerations and current limitations when running CoAP over the non-IP mode. Figure: D.1-1 3GPP CIoT architecture as in [3GPP-TR_23.720] and the LwM2M protocol stack shows the 3GPP CIoT architecture, as described in [3GPP-TR_23.720] and the LwM2M protocol stack. The C-SGN combines the functionality of the MME, S-GW, and P-GW.

3GPP NB-IoT architecture as in [3GPP-TR_23.720] and the LwM2M protocol stack
Figure: D.1-1 3GPP CIoT architecture as in [3GPP-TR_23.720] and the LwM2M protocol stack

As can be seen from the above figure 3GPP defines two transmission paths for NIDD (Non-IP Data Delivery):

  1. via PtP IP SGi tunnel (see [3GPP-TS_23.401])
  2. via Service Capability Exposure Function (SCEF) (see [3GPP-TS_23.682])

When carrying LwM2M over non-IP mode some limitations and considerations apply which are explained in the following sub-sections.

D.2 NIDD via PtP IP SGi tunnel

As specified in [3GPP-TS_23.401], for mobile originated traffic the P-GW is responsible for creating the IP-packets before sending them via the point-to-point tunnel to the AS. For this, the destination IP address and UDP port for PtP tunnelling based on UDP/IP need to be pre-configured on the P-GW.

As specified in [3GPP-TS_23.401], for mobile terminated traffic, in case PtP tunnelling based on UDP/IP is used, the AS sends the data using UDP/IP encapsulation with the IP address of the UE and the 3GPP defined port for “Non-IP” data. The IP-address of the UE is assigned by the P-GW, however, the UE is not aware of its IP address. The P-GW removes the UDP/IP headers and the data is forwarded via the mobile network to the UE.

[3GPP-TS_29.061] provides further information on how to carry NIDD via the SGi interface.

From the above it can be seen that one limitation for the non-IP transport is the need to pre-configure the destination address in the P-GW so that payloads are correctly relayed. Thus, it is not possible to for a LwM2M client to selectively address more than one LwM2M server via its IP address. As a consequence, the LwM2M client cannot apply separate IP addresses for communicating with

  1. different LwM2M Servers
  2. separate LwM2M Server and separate LwM2M Bootstrap Server.

Client/Server initiated bootstrap could still be applied, however, for this the LwM2M Server and LwM2M Bootstrap Server would need to be combined and have the same server URI. From a security perspective it is advisable to keep LwM2M Server and LwM2M Bootstrap Server separate. Using factory bootstrap or smartcard bootstrap mode would remove the need of a LwM2M Bootstrap Server.

Another alternative would be to have an intermediary node between SGi and LwM2M server. Such a node could then inspect the CoAP messages for routing information such as URI-host and forward the messages accordingly to different LwM2M servers.

Further mechanisms to remove the above addressing limitation are for further consideration. E.g. a link layer protocol on top of NAS could re-establish addressing capabilities.

Given the required pre-configuration of the destination IP address in the mobile network an IoT platform provider needs to contact the mobile operator to get device-platform connectivity pre-configured (IP address, port number, dedicated APN if desired).

D.3 NIDD via SCEF

[3GPP-TS_23.682] specifies NIDD via SCEF.

[3GPP-TS_23.682] also gives some guidelines how an AS can retrieve small data via the SCEF and suggests the message types “NIDD configuration request/response”, “NIDD submit request/response”, and “NIDD request/response” (see [3GPP-TS_23.682], clause 5.13). [3GPP-TS_29.122] defines the T8 Reference point between the SCEF and the SCS/AS and specifies the RESTful APIs that allow the SCS/AS to access the services and capabilities provided by 3GPP network entities and securely exposed by the SCEF.

Obviously in non-IP mode the device is not able to address LwM2M server(s) via their IP address. If NIDD via SCEF is selected all data goes via the SCEF. Thus, the UE can only talk to one LwM2M server since there is no additional information available at the IP layer that allows to selectively address more than one LwM2M server. This information would for regular LwM2M be available in the IP header.

An alternative would be to have an intermediary node between SCEF and LwM2M server. Such a node could then inspect the CoAP messages for routing information such as URI-host and forward the messages accordingly to different LwM2M servers.

The LwM2M server needs to identify the UE towards the SCEF via its MSISDN or External Identifier (see [3GPP-TS_23.682]).

D.4 NAS Transport

[3GPP-TS_24.301] defines the transport of user data via the control plane procedure. Two dedicated NAS messages are specified for transferring small data via the MME, see CONTROL PLANE SERVICE REQUEST message and ESM DATA TRANSPORT message in 3GPP [3GPP-TS_24.301]. For initiation of user data transport via the control plane the CONTROL PLAN SERVICE REQUEST message is used which may include ESM DATA TRANSPORT message in its IE “ESM message container”. After the initiation of user data transport via control plane the separate ESM DATA TRANSPORT messages may be used for further transport of user data.

CoAP messages are placed into the IE “User data container” of the ESM DATA TRANSPORT message.

In case DTLS is used the same applies to the DTLS messages.

The user data container has a variable length and the maximum payload size is 32768 bytes. According to [3GPP-TS_23.060] the network shall use a maximum packet size of at least 128 octets (this applies to both uplink and downlink). The maximum uplink packet size that the MS shall use can be provided by the network as a part of the session management configuration via the Protocol Configurations Options (PCO) (see [3GPP-TS_24.008] and [3GPP-TS_27.060]). According to [3GPP-TS_24.301] clause 6.6.4.2, the maximum size for Non-IP link MTU is 1358 octets to prevent fragmentation in the backbone network. The maximum uplink packet size as indicated in the PCO may be retrieved by the LwM2M Server via the Communications Characteristics Object (urn:oma:lwm2m:oma:17).

It has to be noted that there is no segmentation mechanism available for NAS transport. Thus, the LwM2M Client must not exceed the maximum uplink packet size as indicated via the PCO.

Furthermore, the LwM2M Server must not exceed the maximum downlink packet size supported for NAS transport, else it may result in multiple retransmissions in the lower layers effectively undermining the expected results or performance.

The PCO is also used to covey a rate control instruction to the UE i.e. the maximum number of uplink/downlink messages per a specific time unit (see [3GPP-TS_23.401]). This can lead to a delay of LwM2M message delivery in case the rate is exceeded. The LwM2M server can get awareness of any applied rate control via the Serving PLMN Rate Control Resource in the Cellular Network Connectivity Object (urn:oma:lwm2m:oma:10) or via the APN Rate Control Resource in the APN Connection Profile Object (urn:oma:lwm2m:oma:11).

Serving PLMN Rate Control can make the LwM2M message blocked from the LwM2M Server side after the limit of the value crosses. In these scenarios LwM2M Client SHOULD stop expecting responses and wait to cross the period of silence enforced by the 3GPP network control on message flow from LwM2M Server to LwM2M Client.

According to [3GPP-TS_24.301] the CONTROL PLANE SERVICE REQUEST message and the ESM DATA TRANSPORT message include an IE “Release assistance indication” to inform the network whether or not a downlink data transmission (e.g. acknowledgement or response) subsequent to the uplink data transmission is expected. For mobile originating LwM2M traffic this indicator SHOULD be set accordingly.

Note: Data transmission speed for uplink and downlink via NAS is expected to be around 300 bit/s, or more.

D.5 Large data transport with NB-IoT/CAT-M1

Even NB-IoT/CAT-M1 is mainly designed for small data delivery it does not preclude delivery of very infrequent large data (e.g. software update/software patches).

[3GPP-TS_23.401] describes a control/user plane switch which could be used e.g. to switch the device communication from control plane to user plane in case a software update is expected. However, there will be devices which do only support communication via the control plane, in which case these large data transport may not be feasible directly.

IETF has defined segmentation handling at the CoAP layer for large file transfer e.g. firmware updates. Blockwise transfers in [CoAP_BLOCKWISE] and [LwM2M-CORE] captures the details in LwM2M Object Firmware Update (ID:5)

CoAP block transfer MAY be used with for carrying CoAP over NB-IoT/CAT-M1. This option can be used with IP-mode and non-IP-mode.

An alternative approach is the use of CoAP over TCP. Obviously, this option works only with the IP-mode.

D.6 Message buffering

NB-IoT/CAT-M1 devices are expected to be in a sleeping and power saving mode much or most of the time to enable a battery lifetime of several years. In case a device is not reachable, like device in sleeping mode or for other reasons like applied mobile network controls, downlink messages needs to be buffered. 3GPP has defined such buffering operation as “extended buffering” at the SCEF (see [3GPP-TS_23.682]) and the S-GW (see [3GPP-TS_23.401]).

It has to be noted that there is a potential issue with DTLS timeout and CoAP CON retransmission timer if the messages are buffered in the mobile network, this could lead to the buffer being filled up with retransmissions. Furthermore, in case LwM2M queue mode and network buffering are both applied then this could lead to the message being stored in each buffer resulting in duplicated delivery of the message after the device wakes up. One way for avoiding this would be to use only LWM2M queue mode for buffering messages while the device is not reachable due to sleeping mode or other reasons. In the case that LwM2M queue mode is planned to be used, “extended buffering” in the network should be deactivated. According to [3GPP-TS_23.401] “extended buffering” can be de-activated per APN, or per subscriber.

Alternatively, the LwM2M server could be configured to only send messages when the device is awake. Obvious precondition for this would be the LwM2M server being aware of the device state.

Editor’s note: The device state info is available at the MME which informs the SCEF when the device has woken up from power saving mode (see [3GPP-TS_23.682]). A trigger mechanism from the SCEF to AS could be used, refer ENCap-M2M API from OMA ARC for such API availability.

It has to be noted that certain NB-IoT/CAT-M1 implementations need to support also time critical use cases e.g. fire alarms.

D.7 NB-IoT/CAT-M1 transport configuration options

Various configuration options for NB-IoT transport are provided via the ConnMgmt enabler.

Editor’s note: Reference to be added

D.8 Timer considerations

D.8.1 Introduction

3GPP Rel-13 NB-IoT/CAT-M1 is aimed at constrained low power IoT devices which require infrequent small data transfer and have a battery life of ~10 years. To minimise power consumption these devices use certain features such as Power Save Mode and extended Idle Mode DRX (eDRX) which govern how often the device wakes up, stays up and reachable. Effective use of these parameters in conjunction with LwM2M Registration Life Time, min/max notify periods, and – if LwM2M queue mode operation is used - ACK_TIMEOUT will help the device to have synchronised set of activities that could optimise its power consumption by avoiding unnecessary wake ups and transmissions.

D.8.2 3GPP Parameters

Table: D.8.2-1 3GPP Parameters
Parameter Range Purpose/how it’s used by the device
PSM Timer, Extended T3412 10min-992 days1 Max interval between periodic TAU if there is no other transmission from the device. During this time the device is considered as unreachable and can thereby shut down/deactivate.
Active Timer, T3324 2sec-31 min The time the UE has to stay up and remain reachable after transitioning to idle state in case there is pending data from the NW to send out. At the end of T3324 UE can shut down and deactivate.
Extended DRX2 5.12sec- 174 min Extended Idle mode DRX
Higher Priority PLMN Search Timer Interval between periodic searches for higher priority PLMNs when camped on a visited PLMN, i.e. roaming scenario; based on SIM configuration, EFHPPLMN ([3GPP-TS_31.102], section 4.2.6)
Rate Control TBD Determines the number of allowed uplink PDU transmissions per deci hour per APN as well as per serving PLMN

Note 1: Table 10.5.163a in [3GPP-TS_24.008] specifies range N to 31*N in increments of one where the units of N can be 2 seconds, 30 seconds, 1 min, 10 min, 1 hour, 10 hour or 320 hours. In the context of NB-IoT units of 1 or 10 hours will probably be used in most scenarios

Note 2: Extended DRX and PSM can coexist and be configured together.

PSM Timer (Extended T3412), Active Timer (T3324) and Extended DRX can be requested by the device from the network by inclusion of requested values in Attach or TAU requests. On accepting the device request, the network will provide the device with values for these timers which the device should use.

The LwM2M server can configure the values on Resources which the device should request from the network. By observing this resource, the LwM2M also receives the finally applied timer in case the network has not accepted the device’s request.

D.8.3 LwM2M Parameters

Table: D.8.3-1 LwM2M Parameters
Parameter Range Purpose/how it’s used by the device
Registration Life Time Max. interval between client performing registration updates
Pmin Min. time in second between sending notifications for a resource if any of the notify conditions are met
Pmax Max. time in seconds between sending successive notifications for a resource if none of other notify conditions are satisfied
ACK_TIMEOUT CoAP timer used with LwM2M queue mode operation. The LwM2M Client MUST wait at least ACK_TIMEOUT seconds from the last CoAP message it sent to the LwM2M Server before intentionally going offline

D.8.4 Interactions between parameters

From the two tables above it is clear that how often the device wakes up, transmits data and stays awake, is controlled by a combination of parameters defined by 3GPP and OMA that need to be configured in unison to maximise device power efficiency. For example, in the absence of any service data transmission, the device still has to wake up on a regular basis to: a) update its registration with the LwM2M server to make sure its registration stays valid and b) carry out periodic TAU to meet 3GPP requirements. If parameters are configured such that Registration lifetime <= T3412, then the need to perform TAU will automatically be eliminated because when the registration update is performed by the device, the periodic TAU timer will automatically be reset. However, if T3412 < Registration lifetime, then the device either wakes up twice to carry out these procedures separately, or unilaterally decides to update its registration on expiry of T3412 which will result in the LwM2M server receiving updates more frequently than it had asked for.

Both Active Timer (T3324) and CoAP MAX_TRANSMIT_WAIT are aimed to achieve the same result, namely keeping the device awake long enough to allow queued messages to be sent to the device. Depending on where the queuing occurs, only one of these timers is actually required and can be meaningfully used. It’s also worth noting that these timers do not start at the same time, MAX_TRANSMIT_WAIT is started after last transmission, while T3324 starts later when the device has released the connection and returned to idle state.

From 3GPP perspective eDRX determines how often the device needs to wake up and monitor its paging channel. From LwM2M perspective, a device that is monitoring a sensor at the minimum needs to wake up every Pmax to sample sensor data and transmit its value. It also does not need to wake up any more frequently than Pmin to read the sensor data, assuming no filtering and averaging. Pmin, Pmax and eDRX need to be configured such that a device can schedule its activities to minimise the number of times it needs to wake up and transmit data; this is also contingent on any configured Rate Control value being in line with Pmin and Pmax.

D.8.5 Timer implementation options

Effective use of 3GPP timers in conjunction with LwM2M timers will help the device to have synchronised set of activities that could optimise its power consumption by avoiding unnecessary wake ups and transmissions.

The following recommendations apply:

A customer solution designer, will define the values of Pmin and Pmax, and the Infrastructure solution provider will define the values of Extended T3412, LwM2M Registration lifetime and eDRX.

For efficient interaction between mechanisms, the following relationships can be maintained between values of LwM2M and 3GPP parameters: