ETSI TS 118 110 V2.4.1 (2016-09)

TECHNICAL SPECIFICATION
oneM2M;
MQTT Protocol Binding
(oneM2M TS-0010 version 2.4.1 Release 2)

(oneM2M TS-0010 version 2.4.1 Release 2) 2 ETSI TS 118 110 V2.4.1 (2016-09)

Reference
RTS/oneM2M-000010v200
Keywords
IoT, M2M, protocol
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 3 ETSI TS 118 110 V2.4.1 (2016-09)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Conventions . 7
5 Introduction . 8
5.1 Use of MQTT . 8
5.2 Binding overview . 8
5.2.1 Introduction. 8
5.2.2 Scenarios . 9
5.2.2.1 MQTT server co-located within a node . 9
5.2.2.2 MQTT server located independently from nodes . 10
5.2.3 Configurations . 10
5.2.3.1 AE to IN . 10
5.2.3.2 AE to MN . 11
5.2.3.3 MN to IN . 12
5.2.3.4 AE to MN to IN . 12
5.2.3.5 AE to IN (Independent scenario) . 13
5.2.3.6 AE to MN (Independent scenario) . 13
5.2.3.7 MN to IN (Independent scenario) . 13
5.2.3.8 AE to MN to IN (Independent scenario) . 14
6 Protocol Binding . 15
6.1 Introduction . 15
6.2 Use of MQTT . 15
6.3 Connecting to MQTT . 15
6.4 Sending and Receiving Messages . 16
6.4.1 Request and Response Messages . 16
6.4.2 Sending a Request . 17
6.4.3 Listening for and responding to a Request . 18
6.4.4 Initial Registration . 18
6.4.5 Request/Response Message Flow . 19
6.5 Primitive Mapping . 20
6.5.1 Request primitives . 20
6.5.2 Response primitives . 21
6.5.3 Serialization Format Negotiation . 22
6.5.4 Content-type . 22
6.6 Format used in pointOfAccess strings . 22
7 Security. 23
7.1 Introduction . 23
7.2 Authorization . 23
7.3 Authentication . 24
7.4 Authorization by the MQTT Server . 24
7.5 General Considerations . 25
Annex A (informative): Overview of MQTT . 26
A.0 Introduction . 26
A.1 MQTT features . 26
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 4 ETSI TS 118 110 V2.4.1 (2016-09)
A.2 MQTT implementations . 27
A.3 MQTT Details . 27
A.3.1 Addressing a message - Topics and Subscriptions . 27
A.3.2 Reliability . 28
A.3.3 Retained Messages . 29
History . 30

ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 5 ETSI TS 118 110 V2.4.1 (2016-09)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Partnership Project oneM2M (oneM2M).
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 6 ETSI TS 118 110 V2.4.1 (2016-09)
1 Scope
The present document specifies the binding of Mca and Mcc primitives (message flows) onto the MQTT protocol. It
specifies:
1) How a CSE or AE connects to MQTT.
2) How an Originator (CSE or AE) formulates a Request as an MQTT message, and transmits it to its intended
Receiver.
3) How a Receiver listens for incoming Requests.
4) How that Receiver can formulate and transmit a Response.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] OASIS MQTT Version 3.1.1 (29 October 2014). OASIS Standard. Edited by Andrew Banks and
Rahul Gupta.
NOTE: Available at http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html.
[2] ETSI TS 118 101: "oneM2M Functional Architecture (oneM2M TS-0001)".
[3] ETSI TS 118 104: "oneM2M; Service Layer Core Protocol Specification (oneM2M TS-0004)".
[4] IETF RFC 793 (September 1981): "Transmission Control Protocol - DARPA Internet Program -
Protocol Specification", J. Postel.
NOTE: Available at http://www.ietf.org/rfc/rfc793.txt.
[5] IETF RFC 5246 (August 2008): "The Transport Layer Security (TLS) Protocol Version 1.2",
T. Dierks.
NOTE: Available at http://tools.ietf.org/html/rfc5246.
[6] IETF RFC 6455 (December 2011): "The WebSocket Protocol", I. Fette.
NOTE: Available at http://tools.ietf.org/html/rfc6455.
[7] ETSI TS 118 103: "oneM2M; Security solutions (oneM2M TS-0003)".
[8] IETF RFC 3986 (January 2005): "Uniform Resource Identifier (URI): Generic Syntax",
T. Berners-Lee.
NOTE: Available at https://tools.ietf.org/html/rfc3986.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 7 ETSI TS 118 110 V2.4.1 (2016-09)
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] oneM2M Drafting Rules.
NOTE: Available at http://www.onem2m.org/images/files/oneM2M-Drafting-Rules.pdf.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
originator [2]: actor that initiates a Request
NOTE: An Originator can either be an Application or a CSE.
receiver [2]: actor that receives the Request
NOTE: A Receiver can be a CSE or an Application.
resource [2]: uniquely addressable entity in oneM2M System such as by the use of a Uniform Resource Identifier
(URI)
NOTE: A resource can be accessed and manipulated by using the specified procedures.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 118 101 [2] and the following apply:
ADN Application Dedicated Node
ADN-AE AE which resides in the Application Dedicated Node
AE Application Entity
ASN Application Service Node
CSE Common Service Entity
IN Infrastructure Node
IN-AE Application Entity that is registered with the CSE in the Infrastructure Node
IN-CSE CSE which resides in the Infrastructure Node
MN Middle Node
MN-CSE CSE which resides in the Middle Node
TLS Transport Level Security
4 Conventions
The keywords "Shall", "Shall not", "May", "Need not", "Should", "Should not" in the present document are to be
interpreted as described in the oneM2M Drafting Rules [i.1].
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 8 ETSI TS 118 110 V2.4.1 (2016-09)
5 Introduction
5.1 Use of MQTT
This binding makes use of MQTT to provide reliable two-way communications between two parties (AEs and CSEs). It
uses the following features of MQTT:
• Durable Sessions, providing Store and Forward in cases where network connectivity is not available.
• MQTT's "QoS 1" message reliability level. This provides reliability without incurring the overhead implied by
QoS 2.
• NAT traversal (neither of the two parties is required to have prior knowledge of the other party's IP address).
• Dynamic topic creation and wild-carded subscription filters.
It does not use the following features:
• One-to-many publish/subscribe.
• Retained Messages.
• Will Messages.
• QoS 0 or QoS 2 message reliability levels.
5.2 Binding overview
5.2.1 Introduction
The MQTT protocol binding specifies how the Mca or Mcc request and response messages are transported across the
MQTT protocol. Both communicating parties (AEs and CSEs) typically make use of an MQTT client library, and the
communications are mediated via the MQTT server. There is no need for the client libraries or the server to be provided
by the same supplier, since the protocol they use to talk to each other is defined by the MQTT specification [1].
Furthermore, the binding does not assume that the MQTT client libraries or server implementations are necessarily
aware that they are being used to carry Mca, Mcc or any other oneM2M-defined primitives.
The binding is defined in terms of the MQTT protocol flows that take place between the client libraries and the MQTT
server in order to effect the transport of an Mca or Mcc message.
There are two scenarios depending on the location of MQTT server: MQTT server co-located within a node, and MQTT
server located independently from nodes.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 9 ETSI TS 118 110 V2.4.1 (2016-09)
5.2.2 Scenarios
5.2.2.1 MQTT server co-located within a node

Figure 5.2.2.1-1: MQTT server co-located scenario
Figure 5.2.2.1-1 shows a protocol segment view of the MQTT server co-located scenario. In this scenario, all oneM2M
nodes (ADN, ASN, MN, IN) include one or more MQTT clients. MQTT servers are provided within MN and IN.
In this scenario, the protocol segments are illustrated as follows.
Table 5.2.2.1-1: Protocol segment for MQTT server co-located scenario
Protocol Segment oneM2M Message Transported MQTT Interaction
PS1 Mca (AE of ADN to CSE of IN) Client in ADN to Server in IN
PS2 Mca (AE of ADN to CSE of MN) Client in ADN to Server in MN
PS3 Mcc (CSE of ASN to CSE of MN) Client in ASN to Server in MN
PS4 Mcc (CSE of ASN to CSE of IN) Client in ASN to Server in IN
PS5 Mcc (CSE of MN to CSE of MN) Client in MN to Server in MN
PS6 Mcc (CSE of MN to CSE of IN) Client in MN to Server in IN
PS7 Mcc' (CSE of IN to CSE of IN) Client in IN to Server in IN

ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 10 ETSI TS 118 110 V2.4.1 (2016-09)
5.2.2.2 MQTT server located independently from nodes

Figure 5.2.2.2-1: MQTT server independently located scenario
Figure 5.2.2.2-1 shows a protocol segment view in which the MQTT server is located independently from the oneM2M
nodes. In this scenario, all oneM2M nodes (ADN, ASN, MN, IN) include one or more MQTT clients. MQTT servers
exist independently, which means the servers are located outside of the nodes.
In this scenario, the protocol segments are illustrated as follows.
Table 5.2.2.2-1: Protocol segment for MQTT server independently located scenario
Protocol Segment oneM2M Message Transported MQTT Interaction
PS1 Mca (AE of ADN to CSE of IN) Client in ADN to Server
PS2 Mca (AE of ADN to CSE of MN) Client in ADN to Server
PS3 Mcc (CSE of ASN to CSE of MN) Client in ASN to Server
PS4 Mcc (CSE of ASN to CSE of IN) Client in ASN to Server
PS5 Mcc (CSE of MN to CSE of MN) Client in MN to Server
Mcc (CSE of MN to CSE of ASN)
Mca (CSE of MN to AE of ADN)
PS6 Mcc (CSE of MN to CSE of MN) Client in MN to Server
Mcc (CSE of MN to CSE of IN)
PS7 Mcc (CSE of IN to CSE of MN) Client in IN to Server
Mcc (CSE of IN to CSE of ASN)
Mca (CSE of IN to AE of ADN)
The next four clauses show the four configurations in which the MQTT binding can be used in the co-located scenario,
followed by similar configurations in the independently-located scenario.
NOTE: Other configurations are possible, but they are currently out of scope.
5.2.3 Configurations
5.2.3.1 AE to IN
This configuration, illustrated in figure 5.2.3.1-1, allows an AE to connect to an IN via MQTT.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 11 ETSI TS 118 110 V2.4.1 (2016-09)

Figure 5.2.3.1-1: Using MQTT between AE and IN-CSE
The MQTT server is co-located with the IN-CSE and allows connection of the ADN-AEs (typically devices) and/or
IN-AEs. It can store and forward messages if there is a gap in the connectivity with the devices. Note that the AEs each
establish their own separate TCP/IP connection with the MQTT server. Thus the server shall have an accessible IP
address, but AEs need not have.
5.2.3.2 AE to MN
This configuration, illustrated in figure 5.2.3.2-1, allows an ADN-AE to connect to an IN via MQTT.

Figure 5.2.3.2-1: Using MQTT between AE and MN-CSE
This configuration is very similar to the AE-IN configuration shown in clause 5.2.3.1, except that the MQTT server is
hosted on the MN rather than the IN. Onwards connection to the IN-CSE is via a different transport protocol.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 12 ETSI TS 118 110 V2.4.1 (2016-09)
5.2.3.3 MN to IN
This configuration, illustrated in figure 5.2.3.3-1, allows an MN to connect to an IN via MQTT.

Figure 5.2.3.3-1: Mcc using MQTT between MN and IN
The MQTT server is co-located with the IN-CSE and allows connection of the MNs (typically in-field gateway boxes).
It can store and forward messages if there is a gap in the connectivity with the gateways. Note that the MNs each
establish their own separate TCP/IP connections with the MQTT server. Thus the server shall have an accessible IP
address, but MNs need not have.
5.2.3.4 AE to MN to IN
This configuration, illustrated in figure 5.2.3.4-1, is a combination of the previous two.

Figure 5.2.3.4-1: Mca and Mcc both using MQTT
In this configuration the two MQTT servers are independent from each other (that is to say they do not have a shared
topic space). Any interactions between the ADN-AE and the IN-CSE are mediated by the MN-CSE.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 13 ETSI TS 118 110 V2.4.1 (2016-09)
5.2.3.5 AE to IN (Independent scenario)
This configuration, illustrated in figure 5.2.3.5-1, allows an AE to connect to an IN via MQTT.

Figure 5.2.3.5-1: Using MQTT between AE and IN-CSE
The MQTT server is an independent entity, located outside of the nodes. In order to deliver Mca messages, MQTT
clients within ADN-AE/IN-AE and IN-CSE connect to the MQTT server. After the clients establish TCP/IP connection
with the MQTT server, Mca messages between ADN-AE/IN-AE and IN-CSE can be transported via the MQTT server.
5.2.3.6 AE to MN (Independent scenario)
This configuration, illustrated in figure 5.2.3.6-1, allows an ADN-AE to connect to an IN via MQTT.

Figure 5.2.3.6-1: Using MQTT between AE and MN-CSE
In this configuration, the MQTT server is an independent entity, located outside of the nodes. MQTT clients within
ADN-AE and MN-CSE are connected to the MQTT server, and the MQTT server stores and forwards the Mca
messages between ADN-AE and MN-CSE. In addition, this figure shows that the onwards connection to the IN-CSE is
via a different transport protocol.
5.2.3.7 MN to IN (Independent scenario)
This configuration, illustrated in figure 5.2.3.7-1, allows an MN to connect to an IN via MQTT.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 14 ETSI TS 118 110 V2.4.1 (2016-09)

Figure 5.2.3.7-1: Mcc using MQTT between MN and IN
In this configuration, the MQTT server is an independent entity, located outside of nodes. Mcc message delivery
between MN-CSE and IN-CSE are performed via the independently located MQTT server. As introduced in the
previous clauses, in order to send messages, each MQTT client within MN-CSE and IN-CSE connects to the MQTT
server and Mcc messages are transported via MQTT server.
5.2.3.8 AE to MN to IN (Independent scenario)
This configuration, illustrated in figure 5.2.3.8-1, is a combination of the previous two.

Figure 5.2.3.8-1: Mca and Mcc both using MQTT
In this configuration, the MQTT clients of ADN-AE and MN-CSE and IN-CSE connect to the independently located
MQTT server. Any interactions such as Mca or Mcc message delivery among the ADN-AE and the MN-CSE and the
IN-CSE are mediated by the MQTT server.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 15 ETSI TS 118 110 V2.4.1 (2016-09)
6 Protocol Binding
6.1 Introduction
In this clause the use of MQTT is profiled and the key elements of the binding are defined:
1) How a CSE or AE connects to MQTT.
2) How an Originator (CSE or AE) formulates a Request as an MQTT message, and transmits it to its intended
Receiver.
3) How a Receiver listens for incoming Requests, and how it formulates and transmits a Response.
4) How the Mca and Mcc CRUD operations map to MQTT messages.
For more information on MQTT itself see clause A or refer to the MQTT specification [1].
6.2 Use of MQTT
MQTT includes reliability features which allow recovery from loss of network connectivity without requiring explicit
involvement of the applications that are using it, however to do this it requires an underlying network protocol that
provides ordered, lossless, bi-directional connections. The MQTT specification [1] does not mandate a particular
underlying protocol, so this binding specification restricts the choice of underlying protocol: it shall be one of the
following:
• Raw TCP/IP [4].
• TCP/IP with Transport Level Security (TLS) [5].
• WebSocket [6] - either with or without the use of TLS.
6.3 Connecting to MQTT
In order to communicate, the two client parties (AE and CSE or CSE and CSE) shall connect to a common MQTT
server. The MQTT server shall be hosted in one of the two nodes or shall exist as an independent external entity,
following one of the configuration patterns shown in clause 5.2.
Once each party has located the address of the MQTT server, it then connects to it using the standard MQTT
CONNECT protocol packet. The following additional considerations apply:
• The CONNECT packet contains a Client Id as described in clause A.3.2. The Client Ids have to be unique at
least among all clients that connect to a given MQTT server instance (this is a requirement imposed by the
MQTT protocol). This condition will be satisfied if an AE uses its AE-ID and a CSE uses its CSE-ID. See
clause 7 of ETSI TS 118 101 [2] for a discussion of these Identifiers. The prefix A:: or C:: shall be added to
the ID to show whether it is an AE-ID or a CSE-ID as these ID spaces are not distinct.

The AE-ID or CSE-ID may not be known during the initial registration process, in which case the client shall
use some other appropriate unique ID.
• A client shall set the "Clean Session" flag in the CONNECT packet to false. This means that MQTT Session
state related to that client will be retained by the MQTT Server in the event of a disconnection (deliberate or
otherwise) of that client.
• A client shall not set the "Will Flag", so Will Messages are not enabled.
• A client may choose to provide a non-zero MQTT KeepAlive value or to provide a KeepAlive of 0 (this
disables the MQTT KeepAlive).
• The MQTT server may require that a client provides a User Name and a password (or other credential). For
more information see clause 7.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 16 ETSI TS 118 110 V2.4.1 (2016-09)
A client might choose to keep the MQTT connection open permanently (restarting it as soon as possible after any
unforeseen connection loss), it might choose to connect only when it wants to act as an Originator, or it might choose to
connect based on the associated with a relevant oneM2M resource.
Once a client has connected to the MQTT server it can then communicate (subject to authorization policies) with any
other client connected to its server. There is no need for it to create another connection if it wants to communicate with
a different counter-party.
When a client determines that it no longer wishes to participate in an MQTT Session with its MQTT Server it shall
perform the following steps:
• Disconnect from that server, if it is currently connected.
• Reconnect with the cleanSession flag set to true.
• Disconnect again.
These steps delete any state that the MQTT server might be holding on behalf of the client.
6.4 Sending and Receiving Messages
6.4.1 Request and Response Messages
An MQTT Control Packet consists of up to three parts: a fixed header, a variable header, a payload. The control packet
format is depicted in Figure 6.4.1-1. MQTT does not have a data model to describe or constrain the content of its
Application Message payloads (to that extent it is similar to a TCP socket). Mca and Mcc request messages shall be
serialized into XML or JSON following the serialization process defined in clause 6.5.

Figure 6.4.1-1: Message format of MQTT Control Packet
The fixed header includes information about the packet type, flags specific to packet type and the packet length.
Figure 6.4.1-2 shows the fixed header's structure.

Figure 6.4.1-2: Fixed header structure
The packet type field in figure 6.4.1-2 is used to define the MQTT Control packet type. It is a 4-bit field which possible
values are listed in the Table 6.4.1-1. When a oneM2M Request/Response message is bound to MQTT, its packet type
shall have value 3, i.e. the Request/Response message is delivered in an MQTT PUBLISH packet.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 17 ETSI TS 118 110 V2.4.1 (2016-09)
Table 6.4.1-1: MQTT Control Packet Types
Reserved 0 Reserved for future use
CONNECT 1 Client request to connect to server
CONNACK 2 Connect acknowledgement
PUBLISH 3 Publish message
PUBACK 4 Publish message acknowledgement
PUBREC 5 Publish received (QoS=2)
PUBREL 6 Publish release (QoS=2)
PUBCOMP 7 Publish complete (QoS=2)
SUBSCRIBE 8 Client subscribe request
SUBACK 9 Subscribe acknowledgement
UNSUBSCRIBE 10 Client unsubscribe request
UNSUBACK 11 Unsubscribe acknowledgement
PINGREQ 12 Ping request
PINGRESP 13 Ping response
DISCONNECT 14 Client disconnection request
Reserved 15 Reserved for future use

Figure 6.4.1-3: Flags for the PUBLISH packet
Figure 6.4.1-3 shows the flags specific to MQTT PUBLISH packet. The QoS field represents the QoS level of the
PUBLISH packet with possible values of 1, 2 or 3. However, since oneM2M messages are idempotent, they should be
sent with MQTT QoS 1.
NOTE: MQTT packets are subjected to a theoretical maximum message size of 256 MB, but it is good practice
not to send packets that are bigger than a 100kB. If a larger amount of data needs to be sent, it should be
segmented into multiple PUBLISH packets.
6.4.2 Sending a Request
A request is transmitted by sending it as an MQTT PUBLISH protocol packet to the MQTT Server. It uses a Topic that
identifies both the Originator and the Receiver of the request as follows:
• /oneM2M/req///
- "oneM2M" is a literal string identifying the topic as being used by oneM2M.
- is the SP-relative-AE-ID or SP-relative-CSE-ID of the entity that sends the request on this
hop, omitting any leading "/" . In the AE-ID case, any "/" characters embedded in the ID shall be
replaced with ":" characters.
- is the SP-relative-AE-ID or SP-relative-CSE-ID of the Receiver (AE, Transit CSE or
Hosting CSE) on this hop, omitting any leading "/" . In the AE-ID case, any "/" characters embedded in
the ID shall be replaced with ":" characters.
- "req" is a literal string identifying this as a request.
- is "xml" or "json" indicating the MQTT payload data type as described in clause 6.5.4.
The payload of the MQTT PUBLISH packet is used to carry the request primitive, as described in clause 6.5.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 18 ETSI TS 118 110 V2.4.1 (2016-09)
6.4.3 Listening for and responding to a Request
A Receiver listens for requests arriving via MQTT by subscribing to its Topics using a wildcarded topic filter of the
following form
• /oneM2M/req/+/
- "oneM2M" is a literal string identifying the topic as being used by oneM2M
- + is a wildcard which matches any entity
- is the SP-relative-AE-ID or SP-relative-CSE-ID of the Receiver (AE, Transit CSE or Hosting
CSE), omitting any leading "/" . In the AE-ID case, any "/" characters embedded in the ID shall be
replaced with ":" characters.
- "req" is a literal string identifying this as a request.
When it receives a request, the Receiver shall perform the Core Transport operations associated with the request,
including any access control policy checks. In particular it shall check the request expiration timestamp (if any)
contained in the request, since it is possible that that time might have passed while the message was being stored by
MQTT.
It transmits a response by sending an MQTT PUBLISH packet to a response topic. This takes the form:
• /oneM2M/resp//
- "oneM2M" is a literal string identifying the topic as being used by oneM2M.
- is the SP-relative-AE-ID or SP-relative-CSE-ID of the Receiver (AE, Transit CSE or Hosting
CSE), omitting any leading "/". In the AE-ID case, any "/" characters embedded in the ID shall be
replaced with ":" characters.
- is the SP-relative-AE-ID or SP-relative-CSE-ID of the entity that sent the corresponding
request, omitting any leading "/". In the AE-ID case, any "/" characters embedded in the ID shall be
replaced with ":" characters.
- "resp" is a literal string identifying this as a response.
The Originator shall subscribe to this Topic (either explicitly or using a wildcarded filter) in order to see the response.
The payload of the MQTT PUBLISH packet is used to carry the response primitive, as described in clause 6.5.
6.4.4 Initial Registration
In some security scenarios, an Originator might not initially know its AE-ID or CSE-ID. Initial registration exchanges
can use the communication pattern described in clauses 6.4.1 and 6.4.2 except that they use Topics containing a
credential ID rather than an AE-ID or CSE-ID, as follows:
• /oneM2M/reg_req//
- "oneM2M" is a literal string identifying the topic as being used by oneM2M.
- is the Credential-ID. Any "/" characters embedded in the ID shall be replaced with ":"
characters.
- is the SP-relative-CSE-ID of the Receiver (Transit or Hosting CSE) specified in the
corresponding request, omitting any leading "/".
- "reg_req" is a literal string identifying it as a registration request.
and
• /oneM2M/reg_resp//
- "oneM2M" is a literal string identifying the topic as being used by oneM2M.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 19 ETSI TS 118 110 V2.4.1 (2016-09)
- is the Credential-ID of the Originator in the corresponding request. Any "/" characters
embedded in the ID shall be replaced with ":" characters.
- is the SP-relative-CSE-ID of the Receiver (Transit or Hosting CSE) in the corresponding
request, omitting any leading "/" .
- "reg_resp" is a literal string identifying it as a registration response.
6.4.5 Request/Response Message Flow

Figure 6.4.5-1: Initiating Process in MQTT binding
In the MQTT protocol, each client shall subscribe to the MQTT server to receive messages. As shown in
figure 6.4.5.1-1, the AE or CSE initiates the MQTT binding process by trying to connect to the MQTT server, as
described in clause 6.3.
After each MQTT client successfully connects to the server, it shall subscribe to the MQTT server. The topic names
which each MQTT client subscribes to are "/oneM2M/req/+/" (to receive requests) and
"/oneM2M/resp//+" (to receive replies) where and are both set equal to the ID
(SP-relative-AE-ID or SP-relative-CSE-ID as appropriate).
Accordingly the plus sign (‘+' U+002B) wildcard and the SP-relative-AE-ID or SP-relative-CSE-ID are used in the
topic name within the MQTT SUBSCRIBE packet. This enables the MQTT client to receive the PUBLISH packets
whose target it is. Therefore, through this process, the AE or CSE receives messages if the request/response messages
are published to oneM2M/req// or oneM2M/resp//.
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 20 ETSI TS 118 110 V2.4.1 (2016-09)

Figure 6.4.5-2: Request/Response message delivery over MQTT
As an example, figure 6.4.5-2 illustrates the request/response message delivery over MQTT protocol between AE and
CSE via Mca reference point in oneM2M. The message flow is as follows.
In this scenario, the AE wants to send a Request message to the registered CSE. After that, the AE’s MQTT client
library sends an MQTT PUBLISH packet to the MQTT server with "oneM2M/req/ SP-relative-AE-ID/SP-relative-CSE-
ID" as the topic name. The MQTT PUBLISH packet can include {"op", "fr", "to", "ri", "pc", "ty"} and any other
optional message parameters described in clause 8 of ETSI TS 118 104 [3] in its payload.
After the MQTT server receives the MQTT PUBLISH packet from the MQTT client, the server refers to the topic name
and delivers the message to the intended MQTT client. Finally, the MQTT client library delivers the message to the
CSE.
Regarding the Response message, the MQTT message is sent using "oneM2M/resp//" as its
topic. In order to send a Response message to the requestor, the CSE can use the "fr" information from the received
request message or the topic name of the MQTT PUBLISH packet related with the received request message. After that,
the CSE and sends an MQTT PUBLISH packet to the MQTT server with "oneM2M/resp/ SP-relative-AE-ID/SP-
relative-CSE-ID" as the topic name in this scenario. The MQTT PUBLISH packet can include {"rsc", "fr", "to", "ri",
"pc"} and any other optional message parameters described in clause 8 of ETSI TS 118 104 [3] in its payload.
Similar to the request message delivery from AE to CSE, the MQTT server delivers the published packet to the
intended MQTT client by referring to the topic name. Finally, AE receives the response message from the MQTT client.
6.5 Primitive Mapping
6.5.1 Request primitives
A oneM2M request primitive is made up of a number of control parameters and (optionally) a content part. All the
parameters in these parts are serialized into the payload of an MQTT Publish Packet, using the rules given in clause 8 of
ETSI TS 118 104 [3] applied to m2m:requestPrimitive defined in clause 6.4.1of ETSI TS 118 104 [3].
All the parameters that are present in the primitive shall be serialized, in particular the request shall contain the
mandatory parameters such as Operation, To, From, Request Identifier as specified in clause 8.1.2 of ETSI
TS 118 101 [2] and clause 7.1.1.1 of ETSI TS 118 104 [3].
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 21 ETSI TS 118 110 V2.4.1 (2016-09)
Fixed Variable Payload
Request Resource Originating
Operation To From Content .
Identifier Type Timestamp
operation
optional
mandatory parameters dependent
parameters
parameters
Figure 6.5.1-1: MQTT Request example
An example of an MQTT Request message serialized using JSON is:
{"op": 1, "to": "//xxxxx/2345", "fr": "//xxxxx/99", "rqi": "A1234", "ty": 18, "pc":
{"m2m:sch":{"rn":"schedule1", "se": "* 0-5 2,6,10 * * * *"}}, "ot": 20150910T062032}
• op: short name of Operation parameter specified as m2m:operation in ETSI TS 118 104 [3].
• to: short name of To parameter specified either xs:anyURI [3] or m2m:nhURI [3]. It is an URI of the target
resource.
• fr: short name of From parameter which is an ID of the Originator e.g. either the AE or CSE.
• rqi: short name of Request Identifier specified as m2m:requestID [3].
• ty: short name of Resource Type parameter specified as m2m:resourceType [3].
• pc: short name of Content parameter specified in ETSI TS 118 104 [3].
• ot: short name of Originating Timestamp parameter specified as m2m:timestamp [3].
6.5.2 Response primitives
A oneM2M response primitive is serialized using the rules given in clause 8 of [3] applied to m2m:responsePrimitive
defined in clause 6.4.2 of ETSI TS 118 104 [3].
In particular, each response primitive shall include the Response Status Code parameter to indicate success or failure of
the operation and the Request Identifier parameter.

Figure 6.5.2-1: MQTT Response example
An example of an MQTT Response message serialized using JSON is:
{"rsc": 2000, "rqi": "A1234", "pc": {"m2m:sch":{"se": "* 0-5 2,6,10 * * * *"}}, "to": "//xxxxx/2345", "fr":
"//xxxxx/99"}
• rsc: short name of Response Status Code parameter specified as m2m:responseStatusCode in ETSI
TS 118 104 [3].
ETSI
(oneM2M TS-0010 version 2.4.1 Release 2) 22 ETSI TS 118 110 V2.4.1 (2016-09)
• rqi: short name of Request Identifier specified as m2m:requestID in ETSI TS 118 104 [3].
• pc: short name of Content parameter specified in ETSI TS 118 104 [3].
• to: short name of To parameter specified either xs:anyURI [3] or m2m:nhURI [3]. It is an URI of the target
resource.
• fr: short name of From parameter which is an ID of the Originator e.g. either the AE or CSE.
6.5.3 Serialization Format Negotiation
The request primitive can contain an additional parameter called xM2M-Accept which indicates the serialization format
that the Originator is prepared to accept in a Response.
If the Receiver supports the kind of serialization specified in the request’s xM2M-Accept parameter, the Receiver shall
respond using that serialization. If the Receiver does not support the serialization specified in the request’s xM2M-
Accept parameter, "Not Acceptable" shall be sent as the Response Status Code unless another error code takes
precedence for this response.
If the request does not contain the xM2M-Accept parameter, the Receiver is free to choose to use any oneM2M-
supported serialization, since the requestor has not indicated a preference.
Poss
...