ETSI TS 118 110-2016 oneM2M MQTT Protocol Binding (V2 4 1 oneM2M TS-0010 version 2 4 1 Release 2)《oneM2M(物联网协议联盟) MQTT协议绑定(V2 4 1 OneE2M TS-0010版本2 4 1 发行版本2)》.pdf

《ETSI TS 118 110-2016 oneM2M MQTT Protocol Binding (V2 4 1 oneM2M TS-0010 version 2 4 1 Release 2)《oneM2M(物联网协议联盟) MQTT协议绑定(V2 4 1 OneE2M TS-0010版本2 4 1 发行版本2)》.pdf》由会员分享，可在线阅读，更多相关《ETSI TS 118 110-2016 oneM2M MQTT Protocol Binding (V2 4 1 oneM2M TS-0010 version 2 4 1 Release 2)《oneM2M(物联网协议联盟) MQTT协议绑定(V2 4 1 OneE2M TS-0010版本2 4 1 发行版本2)》.pdf（29页珍藏版）》请在麦多课文档分享上搜索。

1、 ETSI TS 118 110 V1.1.0 (2016-03) oneM2M; MQTT Protocol Binding (oneM2M TS-0010 version 1.5.1 Release 1) TECHNICAL SPECIFICATION ETSI ETSI TS 118 110 V1.1.0 (2016-03)2oneM2M TS-0010 version 1.5.1 Release 1Reference RTS/oneM2M-000010v110 Keywords IoT, M2M, protocol ETSI 650 Route des Lucioles F-06921

2、 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 enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org/standards-search T

3、he 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 suc

4、h 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

5、 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 Notificat

6、ion 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

7、the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2016. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered

8、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 ETSI TS 118 110 V1.1.0 (2016-03)3oneM2M TS-0010 version 1.5.1 Release 1Contents Intellectual Property Rights 5g3Foreword . 5g31 Scope 6g32 Re

9、ferences 6g32.1 Normative references . 6g32.2 Informative references 7g33 Definitions and abbreviations . 7g33.1 Definitions 7g33.2 Abbreviations . 7g34 Conventions 7g35 Introduction 8g35.1 Use of MQTT . 8g35.2 Binding overview . 8g35.2.1 Introduction. 8g35.2.2 Scenarios . 9g35.2.2.1 MQTT server co-

10、located within a node 9g35.2.2.2 MQTT server located independently from nodes 10g35.2.3 Configurations 10g35.2.3.1 AE to IN 10g35.2.3.2 AE to MN 11g35.2.3.3 MN to IN . 12g35.2.3.4 AE to MN to IN 12g35.2.3.5 AE to IN (Independent scenario) 13g35.2.3.6 AE to MN (Independent scenario) 13g35.2.3.7 MN to

11、 IN (Independent scenario) . 13g35.2.3.8 AE to MN to IN (Independent scenario) . 14g36 Protocol Binding 14g36.1 Introduction 14g36.2 Use of MQTT . 15g36.3 Connecting to MQTT . 15g36.4 Sending and Receiving Messages 16g36.4.1 Request and Response Messages 16g36.4.2 Sending a Request . 17g36.4.3 Liste

12、ning for and responding to a Request 17g36.4.4 Initial Registration 18g36.4.5 Request/Response Message Flow . 19g36.5 Primitive Mapping 20g36.5.1 Request primitives 20g36.5.2 Response primitives 21g36.5.3 Serialization Format Negotiation 22g36.6 Format used in pointOfAccess strings 22g37 Security. 2

13、2g37.1 Introduction 22g37.2 Authorization 23g37.3 Authentication 23g37.4 Authorization by the MQTT Server . 24g37.5 General Considerations 25g3Annex A (informative): Overview of MQTT . 26g3A.0 Introduction 26g3A.1 MQTT features . 26g3A.2 MQTT implementations . 27g3ETSI ETSI TS 118 110 V1.1.0 (2016-0

14、3)4oneM2M TS-0010 version 1.5.1 Release 1A.3 MQTT Details 27g3A.3.1 Addressing a message - Topics and Subscriptions . 27g3A.3.2 Reliability . 28g3A.3.3 Retained Messages . 28g3History 29g3ETSI ETSI TS 118 110 V1.1.0 (2016-03)5oneM2M TS-0010 version 1.5.1 Release 1Intellectual Property Rights IPRs es

15、sential 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 potent

16、ially 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

17、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 (

18、oneM2M). ETSI ETSI TS 118 110 V1.1.0 (2016-03)6oneM2M TS-0010 version 1.5.1 Release 11 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 Re

19、quest 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 num

20、ber 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. The following referenced documents are necessary for the application of the present document

21、. 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 Lay

22、er Core Protocol Specification (oneM2M TS-0004)“. 4 IETF RFC 793 (September 1981): “Transmission Control Protocol - DARPA Ineternet 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) P

23、rotocol 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

24、 2005): “ Uniform Resource Identifier (URI): Generic Syntax“, T. Berners-Lee. NOTE: Available at https:/tools.ietf.org/html/rfc3986. ETSI ETSI TS 118 110 V1.1.0 (2016-03)7oneM2M TS-0010 version 1.5.1 Release 12.2 Informative references References are either specific (identified by date of publicatio

25、n 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. The following referenced documents are not necessary for the application

26、 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:/ftp.onem2m.org/Others/Rules_Pages/oneM2M-Drafting-Rules-V1_0_1.doc 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document,

27、 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 su

28、ch 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

29、 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 Mi

30、ddle 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 ETSI TS 118 110 V1.1.0 (2016

31、-03)8oneM2M TS-0010 version 1.5.1 Release 15 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 connect

32、ivity is not available. MQTTs “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 partys IP address). Dynamic topic creation and wild-carded subscripti

33、on 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

34、 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

35、 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 MQT

36、T 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

37、ETSI TS 118 110 V1.1.0 (2016-03)9oneM2M TS-0010 version 1.5.1 Release 15.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 no

38、des (ADN, ASN, MN, IN) include a MQTT client. 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 oneM2M Message Transported MQTT Interaction PS1 Mca (AE of ADN to CSE of IN) Client in ADN to Server in IN PS

39、2 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

40、Server in IN PS7 Mcc (CSE of IN to CSE of IN) Client in IN to Server in IN ETSI ETSI TS 118 110 V1.1.0 (2016-03)10oneM2M TS-0010 version 1.5.1 Release 15.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

41、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 a MQTT client. MQTT servers exists independently, which means the servers are located outside of the nodes. In this scenario, the protocol segments are

42、illustrated as follows. Table 5.2.2.2-1 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

43、of IN) Client in ASN to Server PS5 Mcc (CSE of MN to CSE of MN) Mcc (CSE of MN to CSE of ASN) Mca (CSE of MN to AE of ADN) Client in MN to Server PS6 Mcc (CSE of MN to CSE of MN) Client in MN to Server PS7 Mcc (CSE of IN to CSE of MN) Mcc (CSE of IN to CSE of ASN) Mca (CSE of IN to AE of ADN) Client

44、 in IN to Server PS8 Mcc (CSE of IN to CSE of IN) Client in IN to Server 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 possi

45、ble, 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 ETSI TS 118 110 V1.1.0 (2016-03)11oneM2M TS-0010 version 1.5.1 Release 1Figure 5.2.3.1-1: Using MQTT between AE and IN-

46、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 serv

47、er. 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 conf

48、iguration 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 ETSI TS 118 110 V1.1.0 (2016-03)12oneM2M TS-0010 version 1.5.1 Release 15.2.3.3 MN to IN This configuration, illustrated

49、 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 configur