6.4 Sending and Receiving Messages

6.4.1 Request and Response Messages

6.4.1.0 Introduction

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, Mcc and Mcc' request messages shall be serialized into XML or JSON or CBOR following the serialization process defined in clause 6.5.

The packet type field in Figure 6.4.1.1-1 is used to define the MQTT Control Packet type. It is a 4-bit field which possible values are listed in Table 6.4.1.0-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.

Table 6.4.1.0-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

6.4.1.1 Fixed header of MQTT PUBLISH Packet

The fixed header of the MQTT PUBLISH Packet consists of RETAIN, QoS Level, DUP flag, Packet Type, Remaining Length fields as shown in Figure 6.4.1.1-1. The QoS Level represents the QoS level of the MQTT PUBLISH Packet with possible values of 0, 1 or 2. However, since oneM2M messages are idempotent, the QoS Level should not be set to QoS 2.

Figure 6.4.1.1-1: Fixed header of MQTT PUBLISH Packet

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 100 kB. If a larger amount of data needs to be sent, it should be segmented into multiple PUBLISH packets.

6.4.1.2 Variable header of MQTT PUBLISH Packet

The variable header for the MQTT PUBLISH Packet consists of two fields in the following order: Topic Name, Packet Identifier.

Figure 6.4.1.2-1: Variable header for PUBLISH Packet

The Topic Name identifies the information channel to which payload data is published. The Topic Name for a oneM2M Request Message is specified at clause 6.4.2. The Topic Filter used to listen for and respond to a Request is specified at clause 6.4.3.

The Packet Identifier field is only present in PUBLISH Packets where the QoS level is 1 or 2.

6.4.1.3 Payload of MQTT Control PUBLISH Packet

The payload for the MQTT PUBLISH Packet is a oneM2M Request Message or Response Message as specified in clause 6.5.

6.4.2 Topic Name for Requests

A request is transmitted by sending it as an MQTT PUBLISH Packet to the MQTT Server. The MQTT Publish Packet uses a Topic Name that identifies both the Originator and the Receiver of the request as follows:

• /oneM2M/req/<originator>/<receiver>/<type>

  • "oneM2M" is a literal string identifying the topic as being used by oneM2M.
  • <originator> is the SP-relative-AE-ID or SP-relative-CSE-ID of the entity that sends the request on the Mca or Mcc reference point, omitting any leading "/"s and replacing any other "/" characters with ":" characters.
  • <originator> is the Absolute-CSE-ID of an IN-CSE on the Mcc' reference point, replacing the leading "//" with ":" and replacing any other "/" characters with ":" characters.
  • <receiver> is the SP-relative-AE-ID or SP-relative-CSE-ID of the Receiver (AE, Transit CSE or Hosting CSE) on the Mca or Mcc reference point, omitting any leading "/"s and replacing any other "/" characters with ":" characters.
  • <receiver> is the Absolute-CSE-ID of an IN-CSE on the Mcc' reference point, replacing the leading "//" with ":" and replacing any other "/" characters with ":" characters.
  • "req" is a literal string identifying this as a request.
  • <type> is "xml", "json" or "cbor" indicating the MQTT payload data type as described in clause 6.5.4.

6.4.3 Listening for and responding to a Request

A Receiver listens for requests arriving via MQTT by subscribing using a wildcarded Topic Filter of the following form:

• /oneM2M/req/+/<receiver>/<type>
  • "oneM2M" is a literal string identifying the topic as being used by oneM2M.
  • + is a wildcard which matches any entity.
  • <receiver> is the SP-relative-AE-ID or SP-relative-CSE-ID of the Receiver (AE, Transit CSE or Hosting CSE) on the Mca or Mcc reference point, omitting any leading "/"s and replacing any other "/" characters with ":" characters.
  • <receiver> is the Absolute-CSE-ID of an IN-CSE on the Mcc' reference point, replacing the leading "//" with ":" and replacing any other "/" characters with ":" characters.
  • "req" is a literal string identifying this as a request.
  • <type> is "xml", "json" or "cbor" indicating the MQTT payload data type as described in clause 6.5.4. A wildcard may be used to listen for any type.

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/<originator>/<receiver>/<type>
  • "oneM2M" is a literal string identifying the topic as being used by oneM2M.
  • <receiver> is the SP-relative-AE-ID or SP-relative-CSE-ID of the Receiver (AE, Transit CSE or Hosting CSE) on the Mca or Mcc reference point, omitting any leading "/"s and replacing any other "/" characters with ":" characters.
  • <receiver> is the Absolute-CSE-ID of an IN-CSE on the Mcc' reference point, replacing the leading "//" with ":" and replacing any other "/" characters with ":" characters.
  • <originator> is the SP-relative-AE-ID or SP-relative-CSE-ID of the entity that sent the corresponding request on the Mca or Mcc reference point, omitting any leading "/"s and replacing any other "/" characters with ":" characters.
  • <originator> is the Absolute-CSE-ID of an IN-CSE on the Mcc' reference point, replacing the leading "//" with ":" and replacing any other "/" characters with ":" characters.
  • "resp" is a literal string identifying this as a response.
  • <type> is "xml", "json" or "cbor" indicating the MQTT payload data type as described in clause 6.5.4.

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/<originator>/<receiver>/<type>
  • "oneM2M" is a literal string identifying the topic as being used by oneM2M.
  • <originator> is the Credential-ID. Any "/" characters embedded in the ID shall be replaced with ":" characters.
  • <receiver> 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.
  • <type> is "xml", "json" or "cbor" indicating the MQTT payload data type as described in clause 6.5.4.

and

• /oneM2M/reg_resp/<originator>/<receiver>/<type>
  • "oneM2M" is a literal string identifying the topic as being used by oneM2M.
  • <originator> is the Credential-ID of the Originator in the corresponding request. Any "/" characters embedded in the ID shall be replaced with ":" characters.
  • <receiver> 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.
  • <type> is "xml", "json" or "cbor" indicating the MQTT payload data type as described in clause 6.5.4.

6.4.5 Request/Response Message Flow (Mca or Mcc)

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, 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 Filters with which each MQTT client subscribes are "/oneM2M/req/+/<receiver>/<type>" (to receive requests) and "/oneM2M/resp/<originator>/+/<type>" (to receive replies) where <receiver> and <originator> 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 Filter 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/<originator>/<receiver>/<type>" or "/oneM2M/resp/<originator>/<receiver>/<type>".

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 Originator and Receiver via the Mca/Mcc reference point in oneM2M. The message flow is as follows.

In this flow, the Originator wants to send a Request message to the Receiver. The Originator's MQTT client library sends an MQTT PUBLISH Packet to the MQTT server with "/oneM2M/req/SP-relative-AE-ID/SP-relative-CSE-ID/<type>" as the Topic Name.

The MQTT PUBLISH packet shall include {"op", "fr", "to", "rqi"} and any optional parameters in accordance with the operation (CREATE, RETRIEVE, UPDATE, DELETE, NOTIFY) as specified in clause 7.2.1.1 of oneM2M TS-0004 [3] in its payload.

When 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 Receiver.

After that, the Receiver builds a Topic Name for the Response message of the form "/oneM2M/resp/Originator-ID/Receiver-ID/<type>". The payload of the MQTT PUBLISH Packet shall include {"rsc", "rqi"} and any optional message parameters in accordance with operation (CREATE, RETRIEVE, UPDATE, DELETE, NOTIFY) as specified in clause 7.2.1.2 of oneM2M TS-0004 [3] in its payload.