TIA-5022 008-2015 CoAP Protocol Binding (oneM2M TS-0008-v1 0 1).pdf

1、 TIA-5022.008 October 2015CoAP Protocol Binding (oneM2M TS-0008-v1.0.1) NOTICE TIA Engineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products,

2、 and assisting the purchaser in selecting and obtaining with minimum delay the proper product for their particular need. The existence of such Standards and Publications shall not in any respect preclude any member or non-member of TIA from manufacturing or selling products not conforming to such St

3、andards and Publications. Neither shall the existence of such Standards and Publications preclude their voluntary use by Non-TIA members, either domestically or internationally. Standards and Publications are adopted by TIA in accordance with the American National Standards Institute (ANSI) patent p

4、olicy. By such action, TIA does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the Standard or Publication. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. I

5、t is the responsibility of the user of this Standard to establish appropriate safety and health practices and to determine the applicability of regulatory limitations before its use. Any use of trademarks in this document are for information purposes and do not constitute an endorsement by TIA or th

6、is committee of the products or services of the company. (From Project No. TIA-PN-5022.008, formulated under the cognizance of the TIA TR-50 M2M- Smart Device Communications.) Published by TELECOMMUNICATIONS INDUSTRY ASSOCIATION Technology (b) there is no assurance that the Document will be approved

7、 by any Committee of TIA or any other body in its present or any other form; (c) the Document may be amended, modified or changed in the standards development or any editing process. The use or practice of contents of this Document may involve the use of intellectual property rights (“IPR”), includi

8、ng pending or issued patents, or copyrights, owned by one or more parties. TIA makes no search or investigation for IPR. When IPR consisting of patents and published pending patent applications are claimed and called to TIAs attention, a statement from the holder thereof is requested, all in accorda

9、nce with the Manual. TIA takes no position with reference to, and disclaims any obligation to investigate or inquire into, the scope or validity of any claims of IPR. TIA will neither be a party to discussions of any licensing terms or conditions, which are instead left to the parties involved, nor

10、will TIA opine or judge whether proposed licensing terms or conditions are reasonable or non-discriminatory. TIA does not warrant or represent that procedures or practices suggested or provided in the Manual have been complied with as respects the Document or its contents. If the Document contains o

11、ne or more Normative References to a document published by another organization (“other SSO”) engaged in the formulation, development or publication of standards (whether designated as a standard, specification, recommendation or otherwise), whether such reference consists of mandatory, alternate or

12、 optional elements (as defined in the TIA Procedures for American National Standards) then (i) TIA disclaims any duty or obligation to search or investigate the records of any other SSO for IPR or letters of assurance relating to any such Normative Reference; (ii) TIAs policy of encouragement of vol

13、untary disclosure (see TIA Procedures for American National Standards Annex C.1.2.3) of Essential Patent(s) and published pending patent applications shall apply; and (iii) Information as to claims of IPR in the records or publications of the other SSO shall not constitute identification to TIA of a

14、 claim of Essential Patent(s) or published pending patent applications. TIA does not enforce or monitor compliance with the contents of the Document. TIA does not certify, inspect, test or otherwise investigate products, designs or services or any claims of compliance with the contents of the Docume

15、nt. ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NONINFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY

16、RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES REGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE OR REGULATION, OR THE SAFETY OR HEALTH EFFECTS OF THE CONTENTS OR ANY PRODUCT OR SERVICE REFERR

17、ED TO IN THE DOCUMENT OR PRODUCED OR RENDERED TO COMPLY WITH THE CONTENTS. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIA

18、L DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF DAMAGES

19、IS A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TTA, TTC) Page 2 of 14 This is a draft oneM2M document and should not be relied upon; the final version, if any,

20、 will be made available by oneM2M Partners Type 1. About oneM2M The purpose and goal of oneM2M is to develop technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devi

21、ces in the field with M2M application servers worldwide. More information about oneM2M may be found at: http/www.oneM2M.org Copyright Notification No part of this document may be reproduced, in an electronic retrieval system or otherwise, except as authorized by written permission. The copyright and

22、 the foregoing restriction extend to reproduction in all media. 2015, oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TTA, TTC). All rights reserved. Notice of Disclaimer the final version, if any, will be made available by oneM2M Partners Type 1. Contents 1 Scope 4 2 References 4 2.1 Normative

23、 references . 4 2.2 Informative references . 4 3 Abbreviations and acronyms 4 4 Conventions . 5 5 Overview 5 5.1 Required Features 5 5.2 Introduction of CoAP . 5 5.2.1 Message Format . 5 5.2.2 Caching 6 5.2.2.1 Freshness 6 5.2.2.2 Validity . 6 5.2.3 Blockwise Transfers . 6 6 CoAP Message Mapping 6 6

24、.1 Introduction . 6 6.2 Primitive Mapping to CoAP Message 7 6.2.1 Header 7 6.2.2 Configuration of Token and Options . 7 6.2.2.1 Token 7 6.2.2.2 Content Format Negotiation Options . 7 6.2.2.3 URI Options 8 6.2.2.4 Definition of New Options 8 6.2.2.4.1 From 8 6.2.2.4.2 Request Identifier 8 6.2.2.4.3 N

25、ame . 8 6.2.2.4.4 Originating Timestamp 9 6.2.2.4.5 Request Expiration Timestamp 9 6.2.2.4.6 Result Expiration Timestamp . 9 6.2.2.4.7 Operation Execution Time . 9 6.2.2.4.8 notificationURI of Response Type . 9 6.2.2.4.9 Event Category 9 6.2.2.4.10 Response Status Code 9 6.2.2.4.11 Group Request Ide

26、ntifier 9 6.2.3 Payload . 9 6.2.4 Response Codes Mapping . 9 6.3 Accessing Resources in CSEs 10 6.3.1 Blocking case . 10 6.3.2 Non-Blocking Asynchronous case 11 6.3.3 Non-Blocking Synchronous case 11 6.4 Mapping rules of caching . 11 6.5 Usage of Blockwise Transfers 11 7 Security Consideration . 12

27、Annex A (informative): Example Procedures . 13 A.1 AE Registration 13 History 14 oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TTA, TTC) Page 4 of 14 This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1. 1 S

28、cope The present document will cover the protocol specific part of communication protocol used by oneM2M compliant systems as RESTful CoAP binding. The scope of this specification is (not limited to as shown below): - Binding oneM2M primitives to CoAP messages - Binding oneM2M Response Status Codes

29、to CoAP Response Codes - Defining behaviour of a CoAP Client and Server depending on oneM2M parameters 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 c

30、ited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. The following referenced documents are necessary for the application of the present document. 1 IETF RFC 7252: “The Constrained Application Protocol (CoAP)“. 2 oneM2M T

31、S-0004: “ Service Layer Core Protocol Specification“. 3 IETF draft-ietf-core-block-15: “Blockwise transfers in CoAP“. 4 oneM2M TS-0003: “Security Solutions“. 5 IETF RFC 6347: “Datagram Transport Layer Security Version 1.2“. 2.2 Informative references References are either specific (identified by dat

32、e 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 reference document (including any amendments) applies. The following referenced documents are not necessary for t

33、he application of the present document but they assist the user with regard to a particular subject area. i.1 oneM2M Drafting Rules. NOTE: Available http:/member.onem2m.org/Static_pages/Others/Rules_Pages/oneM2M-Drafting-Rules-V1_0.doc. 3 Abbreviations and acronyms For the purposes of the present do

34、cument, the following abbreviations and acronyms apply: DTLS Datagram Transport Layer Security HTTP Hyper Text Transfer Protocol IP Internet Protocol TCP Transport Control Protocol TLS Transport Layer Security TLV Tag - Length - Value (data structure) oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI,

35、TIA, TTA, TTC) Page 5 of 14 This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Type 1. UDP User Datagram Protocol URI Uniform Resource Identifier 4 Conventions The keywords “Shall“, “Shall not“, “May“, “Need not“, “Shou

36、ld“, “Should not“ in the present document are to be interpreted as described in the oneM2M Drafting Rules i.1. 5 Overview The clause describes which features need to be supported in CoAP layer and introduces a message format and several features of CoAP used in this procotol binding specification. 5

37、.1 Required Features This clause explicitely specifies the required features of the CoAP layer for oneM2M to propery bind oneM2M primitives into CoAP messages. The 4-byte binary CoAP message header is defined in Section 3 of 1. Confirmable (CON), Acknowledgement (ACK) and Reset (RST) messages shall

38、be supported. The Reset message is used to send a error message in response to a malformed Confirmable message in CoAP layer. GET, PUT, POST and DELETE methods shall be supported. oneM2M primitives map to these methods. A subset of Response Code specified in clause 6.2.4 shall be supported for oneM2

39、M Response Status Code parameter mapping. The Uri-Host, Uri-Port, Uri-Path, and Uri-Query shall be supported. The Content-Type Option shall be used to indicate the media types of the payload. The Token Option may be used. Block-wise transfers feature may be supported to carry large payloads. Caching

40、 feature may be supported. 5.2 Introduction of CoAP This clause describes a message format, and caching and block-wise transfers features which may be used to map oneM2M primitives to CoAP messages. 5.2.1 Message Format This clause specifies details about the CoAP 1 message format: CoAP message occu

41、pies the data section of one UDP datagram. CoAP message format supports a 4-byte fixed-size header. Fixed-size header is followed by a Token value of length 0 or 8 bytes. The Token value is followed by a sequence of zero or more CoAP Options in TLV format. CoAP Options are followed by the payload pa

42、rt. For more details on the CoAP message format and the supported header fields, refer 1. oneM2M Partners Type 1 (ARIB, ATIS, CCSA, ETSI, TIA, TTA, TTC) Page 6 of 14 This is a draft oneM2M document and should not be relied upon; the final version, if any, will be made available by oneM2M Partners Ty

43、pe 1. 5.2.2 Caching CoAP 1 supports caching of responses to fulfill future equivalent requests to the same resource. Caching is supported using freshness and validity information carried with CoAP 1 responses. 5.2.2.1 Freshness CoAP server shall use Max-Age CoAP Option to specify the explicit expira

44、tion time for the CoAP Responses resource representation. This indicates that the response is not fresh after its age is greater than the specified number of seconds. Max-Age Option defaults to a value of 60 (seconds). In case, Max-Age Option is not present in the cacheable response, the response sh

45、all not be considered fresh after its age is greater than 60 seconds. The CoAP server shall set the Max-Age Option value to 0 (zero) to prevent or disable caching. The CoAP client, having a fresh stored response, can make new request matching the request for that stored response. In this case, the n

46、ew response shall invalidate the old response. 5.2.2.2 Validity A CoAP endpoint with stored responses but not able to satisfy subsequent requests (for example, the response is not fresh), shall use the ETag Option to perform a conditional request to the CoAP server where the resource is hosted. If t

47、he cached response with the CoAP client is still valid, the server shall include the Max-Age Option in the response along with a code of 2.03 - Valid. This shall update the freshness of the cached response at the CoAP client. If the cached response with the CoAP client is not valid, the server shall

48、 respond with an updated representation of the resource with response code 2.05 - Content. The CoAP client shall use the updated response to satisfy request and may also replace/update the stored or cached response. 5.2.3 Blockwise Transfers CoAP Block 6 Options shall be used when CoAP endpoints nee

49、d to transfer large payloads e.g. firmware, software updates. Instead of relying on IP fragmentation, CoAP Block Option shall be used for transferring multiple blocks of information in multiple request-response pairs. 6 CoAP Message Mapping 6.1 Introduction When AE or CSE binds oneM2M primitives to CoAP messages, or binds CoAP messages to oneM2M primitives, it is required that AE shall host a CoAP client and should host a CoAP server or CSE shall host both a CoAP client and a CoAP server. Basically sing