1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T Y.4500.10 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2018) SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS, NEXT-GENERATION NETWORKS, INTERNET OF THINGS AND SMART CITIES Internet of things an
2、d smart cities and communities Frameworks, architectures and protocols oneM2M MQTT protocol binding Recommendation ITU-T Y.4500.10 ITU-T Y-SERIES RECOMMENDATIONS GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS, NEXT-GENERATION NETWORKS, INTERNET OF THINGS AND SMART CITIES GLOBAL INFORMA
3、TION INFRASTRUCTURE General Y.100Y.199 Services, applications and middleware Y.200Y.299 Network aspects Y.300Y.399 Interfaces and protocols Y.400Y.499 Numbering, addressing and naming Y.500Y.599 Operation, administration and maintenance Y.600Y.699 Security Y.700Y.799 Performances Y.800Y.899 INTERNET
4、 PROTOCOL ASPECTS General Y.1000Y.1099 Services and applications Y.1100Y.1199 Architecture, access, network capabilities and resource management Y.1200Y.1299 Transport Y.1300Y.1399 Interworking Y.1400Y.1499 Quality of service and network performance Y.1500Y.1599 Signalling Y.1600Y.1699 Operation, ad
5、ministration and maintenance Y.1700Y.1799 Charging Y.1800Y.1899 IPTV over NGN Y.1900Y.1999 NEXT GENERATION NETWORKS Frameworks and functional architecture models Y.2000Y.2099 Quality of Service and performance Y.2100Y.2199 Service aspects: Service capabilities and service architecture Y.2200Y.2249 S
6、ervice aspects: Interoperability of services and networks in NGN Y.2250Y.2299 Enhancements to NGN Y.2300Y.2399 Network management Y.2400Y.2499 Network control architectures and protocols Y.2500Y.2599 Packet-based Networks Y.2600Y.2699 Security Y.2700Y.2799 Generalized mobility Y.2800Y.2899 Carrier g
7、rade open environment Y.2900Y.2999 FUTURE NETWORKS Y.3000Y.3499 CLOUD COMPUTING Y.3500Y.3999 INTERNET OF THINGS AND SMART CITIES AND COMMUNITIES General Y.4000Y.4049 Definitions and terminologies Y.4050Y.4099 Requirements and use cases Y.4100Y.4249 Infrastructure, connectivity and networks Y.4250Y.4
8、399 Frameworks, architectures and protocols Y.4400Y.4549 Services, applications, computation and data processing Y.4550Y.4699 Management, control and performance Y.4700Y.4799 Identification and security Y.4800Y.4899 Evaluation and assessment Y.4900Y.4999 For further details, please refer to the list
9、 of ITU-T Recommendations. Rec. ITU-T Y.4500.10 (03/2018) i Recommendation ITU-T Y.4500.10 oneM2M MQTT protocol binding Summary Recommendation ITU-T Y.4500.10 specifies the binding of Mca and Mcc primitives (message flows), defined in the service layer core protocol, on to the MQTT transport protoco
10、l. History Edition Recommendation Approval Study Group Unique ID* 1.0 ITU-T Y.4500.10 2018-03-01 20 11.1002/1000/13505 Keywords oneM2M, MQTT, protocol, security, transport, primitive, message. * To access the Recommendation, type the URL http:/handle.itu.int/ in the address field of your web browser
11、, followed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/1000/11830-en. ii Rec. ITU-T Y.4500.10 (03/2018) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication
12、technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World T
13、elecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In som
14、e areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognize
15、d operating agency. Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words
16、 “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that th
17、e practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation
18、development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are t
19、herefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. NOTE This Recommendation departs slightly from the usual editorial style of ITU-T Recommendations to preserve existing cross-referencing from external documents. ITU 2018 All rights reserved. No part of this
20、publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T Y.4500.10 (03/2018) iii Table of Contents Page 1 Scope . 1 2 References . 1 3 Definitions 2 3.1 Terms defined elsewhere 2 3.2 Terms defined in this Recommendation . 2 4 Abbreviations and a
21、cronyms 2 5 Conventions 3 6 Introduction . 3 6.1 Use of MQTT . 3 6.2 Binding overview . 4 7 Protocol binding 12 7.1 Introduction 12 7.2 Use of MQTT . 12 7.3 Connecting to MQTT . 13 7.4 Sending and receiving messages 15 7.5 Primitive mapping 19 7.6 Format used in pointOfAccess strings 21 8 Security .
22、 21 8.1 Introduction 21 8.2 Authorization 22 8.3 Authentication 22 8.4 Authorization by the MQTT server 23 8.5 General considerations . 24 Annex A oneM2M specification update and maintenance control procedure 25 Appendix I Overview of MQTT . 26 I.0 Introduction . 26 I.1 MQTT features . 26 I.2 MQTT i
23、mplementations . 27 I.3 MQTT details . 27 Bibliography. 30 Rec. ITU-T Y.4500.10 (03/2018) 1 Recommendation ITU-T Y.4500.10 oneM2M MQTT protocol binding 1 Scope This Recommendation specifies the binding of Mca and Mcc primitives (message flows) on to the message queuing telemetry transport (MQTT) pro
24、tocol. It specifies how: 1) a common services entity (CSE) or application entity (AE) connects to MQTT; 2) an Originator (CSE or AE) formulates a request as an MQTT message, and transmits it to its intended receiver; 3) a receiver listens for incoming requests; 4) hat receiver can formulate and tran
25、smit a response. The Recommendation contains oneM2M Release 2 specification oneM2M MQTT protocol binding V2.4.1 and is equivalent to standards of oneM2M partners including ARIB, ATIS b-ATIS.oneM2M.TS0010V241, CCSA b-CCSA M2M-TS-0010, ETSI b-ETSI TS 118 110, TIA, TSDSI b-TSDSI STD T1.oneM2M TS-0010-2
26、.4.1, TTA b-TTAT.MM-TS.0010 and TTC b-TTC TS-M2M-0010. 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions indicated were valid. All Reco
27、mmendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularl
28、y published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T Y.4500.1 Recommendation ITU-T Y.4500.1 (2018), oneM2M Functional architecture. ITU-T Y.4500.4 Recommendation ITU-T Y. 4500.4 (2018), oneM2M Service l
29、ayer core protocol specification. ETSI TS 118 103 ETSI TS 118 103 V2.4.1 (2016), oneM2M; Security solutions (oneM2M TS-0003 version 2.4.1 Release 2). IETF RFC 793 IETF RFC 793 (1981), Transmission control protocol DARPA internet program Protocol specification. IETF RFC 3986 IETF RFC 3986 (2005), Uni
30、form resource identifier (URI): Generic syntax. IETF RFC 5246 IETF RFC 5246 (2008), The transport layer security (TLS) protocol Version 1.2. IETF RFC 6455 IETF RFC 6455 (2011), The WebSocket protocol. OASIS MQTT OASIS (2014), MQTT standard Version 3.1.1. 2 Rec. ITU-T Y.4500.10 (03/2018) 3 Definition
31、s 3.1 Terms defined elsewhere This Recommendation uses the following terms defined elsewhere: 3.1.1 application entity (AE): b-ITU-T Y.4500.11 Represents an instantiation of application logic for end-to-end M2M solutions. 3.1.2 common services entity (CSE): b-ITU-T Y.4500.11 Represents an instantiat
32、ion of a set of common service functions of the M2M environments. Such service functions are exposed to other entities through reference points. 3.2 Terms defined in this Recommendation This Recommendation defines the following terms: 3.2.1 originator: Actor that initiates a request. NOTE An origina
33、tor can either be an application or a common services entity. 3.2.2 receiver: Actor that receives the request. NOTE A receiver can be a common services entity or an application. 3.2.3 resource: Entity in the oneM2M system that is uniquely addressable, e.g., by the use of a uniform resource identifie
34、r (URI). NOTE A resource can be accessed and manipulated by using the specified procedures. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: ADN Application Dedicated Node ADN-AE Application Dedicated Node-Application Entity AE Application Entity ASN Ap
35、plication Service Node CBOR Concise Binary Object Representation CRUD Create-Read-Update-Delete CSE Common Service Entity HTTP Hypertext Transfer Protocol ID Identifier IN Infrastructure Node IN-AE Infrastructure Node- Application Entity IN-CSE Infrastructure Node-Common Service Entity IoT Internet
36、of Things IP Internet Protocol JSON JavaScript Object Notation M2M Machine to Machine MN Middle Node MN-CSE Middle Node-Common Service Entity Rec. ITU-T Y.4500.10 (03/2018) 3 MQTT Message Queuing Telemetry Transport NAT Network Address Translation QoS Quality of Service SP Service Provider TCP Trans
37、mission Control Protocol TLS Transport Level Security URI Uniform Resource Identifier XML Extensible Markup Language 5 Conventions The keywords “shall“, “shall not“, “may“, “need not“, “should“, “should not“ in this Recommendation are to be interpreted as follows. Shall/shall not: Requirements: 1) e
38、ffect on this Recommendation: this Recommendation needs to describe the required feature (i.e., specify a technical solution for the requirement); 2) effect on products: every implementation (M2M solution that complies with this this Recommendation) must support it; 3) effect on deployments: every d
39、eployment (M2M service based on this Recommendation) must use the standardized feature where applicable otherwise interoperability problems with other services could arise for example. Should/should not: Recommendation 1) effect on this Recommendation: this Recommendation needs to describe a solutio
40、n that allows the presence and the absence of the feature; 2) effect on products: an implementation may or may not support it, however support is recommended; 3) effect on deployments: a deployment may or may not use it, however usage is recommended. May/need not: Permission/option 1) effect on this
41、 Recommendation: this Recommendation needs to describe a solution that allows the presence and the absence of the required feature; 2) effect on products: an implementation may or may not support it; 3) effect on deployments: A deployment may or may not use it. 6 Introduction 6.1 Use of MQTT This bi
42、nding 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. 4 Rec. ITU-T Y.4500.10 (03/2018) MQTTs “QoS 1“ message re
43、liability level. This provides reliability without incurring the overhead implied by QoS 2. Network address translation (NAT) traversal neither of the two parties is required to have prior knowledge of the other partys Internet protocol (IP) address. Dynamic topic creation and wild-carded subscripti
44、on filters. It does not use the following features: one-to-many publish or subscribe; retained messages; will messages; QoS 0 or QoS 2 message reliability levels. 6.2 Binding overview 6.2.1 Introduction The MQTT protocol binding specifies how the Mca or Mcc request and response messages are transpor
45、ted 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 t
46、alk to each other is defined by the MQTT specification OASIS MQTT. 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 term
47、s 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 n
48、odes. 6.2.2 Scenarios 6.2.2.1 MQTT server co-located scenario Figure 6.2.2.1-1 shows a protocol segment view of the MQTT server co-located scenario, in which all oneM2M nodes application dedicated node (ADN), application service node (ASN), middle node (MN), infrastructure node (IN) include one or m
49、ore MQTT clients. MQTT servers are provided within MNs and INs. Rec. ITU-T Y.4500.10 (03/2018) 5 Figure 6.2.2.1-1 MQTT server co-located scenario In this scenario, the protocol segments are as listed in Table 6.2.2.1-1. Table 6.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 M
