idnits 2.17.1 draft-becker-core-coap-sms-gprs-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 641 has weird spacing: '... code mid...' -- The document date (February 20, 2017) is 2615 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-silverajan-core-coap-alternative-transports-09 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE K. Kuladinithi, Ed. 3 Internet-Draft ComNets, Hamburg University of Technology 4 Intended status: Standards Track M. Becker 5 Expires: August 24, 2017 Tridonic GmbH & Co KG 6 K. Li 7 Alibaba Group 8 T. Poetsch 9 New York University Abu Dhabi 10 February 20, 2017 12 Transport of CoAP over SMS 13 draft-becker-core-coap-sms-gprs-06 15 Abstract 17 Short Message Service (SMS) of mobile cellular networks is frequently 18 used in Machine-To-Machine (M2M) communications, such as for 19 telematic devices. The service offers small packet sizes and high 20 delays just as other typical low-power and lossy networks (LLNs), 21 i.e. 6LoWPANs. The design of the Constrained Application Protocol 22 (CoAP, RFC7252), that took the limitations of LLNs into account, is 23 thus also applicable to other transports. The adaptation of CoAP to 24 SMS transport mechanisms is described in this document. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 24, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. MO-MT Scenarios . . . . . . . . . . . . . . . . . . . . . 4 66 2.2. MT Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 67 2.3. MO Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Message Exchange for SMS in a Cellular-To-Cellular 70 Mobile-Originated and Mobile-Terminated Scenario . . . . 6 71 4. Encoding Schemes of CoAP for SMS transport . . . . . . . . . 7 72 5. Message Size Implementation Considerations . . . . . . . . . 7 73 6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7.1. New Options for mixed IP operation. . . . . . . . . . . . 8 76 8. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9. Transmission Parameters . . . . . . . . . . . . . . . . . . . 9 78 10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 12.1. CoAP Option Number . . . . . . . . . . . . . . . . . . . 10 82 12.2. URI Scheme Registration . . . . . . . . . . . . . . . . 10 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 13.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Appendix A. SMS encoding . . . . . . . . . . . . . . . . . . . . 12 87 A.1. ASCII-optimized SMS encoding . . . . . . . . . . . . . . 12 88 Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 16 89 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 90 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 This specification details the usage of the Constrained Application 96 Protocol on the Short Message Service (SMS) of mobile cellular 97 networks. 99 1.1. Motivation 101 In some M2M environments, internet connectivity is not supported by 102 the constrained end-points, but a cellular network connection is 103 supported instead. Internet connectivity might also be switched off 104 for power saving reasons or the cellular coverage does not allow for 105 Internet connectivity. In these situations, SMS will be supported, 106 instead of UDP/IP over General Packet Radio Service (GPRS), High 107 Speed Packet Access (HSPA) or Long Term Evolution (LTE) networks. 109 In 3GPP, SMS is identified as the transport protocol for small data 110 transmissions (See [ts23_888] for Key Issue on Machine Type 111 Communication (MTC) Device Trigger and the proposed solutions in 112 Sections 6.2, 6.42, 6.44, 6.48, 6.52, 6.60, and 6.61). In [ts23_682] 113 'Architecture Enhancements to facilitate communications with Packet 114 Data Networks and Applications' SMS is at the moment the only Trigger 115 Delivery (Trigger Delivery using T4). 117 M2M protocols using SMS, e.g. for telematics, are using mostly 118 various diverse proprietary and closed binary protocols with limited 119 publicly available documentation at the moment. 121 In Open Mobile Alliance (OMA) LightweightM2M technical specification 122 [oma_lightweightm2m_ts], SMS is identified as an alternative 123 transport for CoAP messages. 125 1.2. Terminology 127 This document uses the following terminology: 129 CoAP Server and Client 130 The terms CoAP Server and CoAP Client are used synonymously to 131 Server and Client as specified in the terminology section of 132 [RFC7252]. 134 Mobile Station (MS) 135 A Mobile Station includes all required user equipment and software 136 that is needed for communication with a mobile network. As 137 defined in [etsi_ts101_748]. 139 1.3. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 2. Scenarios 147 Several scenarios are presented first for M2M communications with 148 CoAP over SMS. First Mobile-Originating Mobile-Terminating (MO-MT) 149 scenarios are presented, where both CoAP endpoints are in devices in 150 a cellular network. Next, Mobile-Terminating (MT) scenarios are 151 detailed, where only the CoAP server is in a cellular network. 152 Finally, Mobile-Originating (MO) scenarios where the CoAP client is 153 in the cellular network. 155 2.1. MO-MT Scenarios 157 Two mobile cellular terminals communicate by exchanging a CoAP 158 Request and Response embedded into short message protocol data units 159 (PDUs) (depicted in Figure 1). Both terminals are connected via a 160 Short Message Service Centre (SMS-C). 162 CoAP-REQ CoAP-REQ 163 +------+ (SMS) +-------+ (SMS) +------+ 164 | A | --------> | SMS-C | -------> | B | 165 |(cell)| <-------- | | <------- |(cell)| 166 +------+ CoAP-RES +-------+ CoAP-RES +------+ 167 (SMS) (SMS) 169 Figure 1: Cellular and Cellular Communication (only SMS-based) 171 2.2. MT Scenarios 173 An IP host and a mobile cellular terminal communicate by exchanging 174 CoAP Request and Response. The IP host uses protocols offered by the 175 SMS-C (e.g. Short Message Peer-to-Peer (SMPP [smpp]), Computer 176 Interface to Message Distribution (CIMD [cimd]), Universal Computer 177 Protocol/External Machine Interface (UCP/EMI [ucp])) to submit a 178 short message for delivery, which contains the CoAP Request (depicted 179 in Figure 2). 181 CIMD CoAP-REQ 182 +------+ SMPP +-------+ (SMS) +------+ 183 | A | --------> | SMS-C | ---------> | B | 184 | (IP) | <-------- | | <--------- |(cell)| 185 +------+ +-------+ CoAP-RES +------+ 186 (SMS) 188 Figure 2: IP and Cellular Communication 190 There are service providers that offer SMS delivery and notification 191 using an HTTP/REST interface (depicted in Figure 3). 193 HTTP-REQ CIMD CoAP-REQ 194 +------+ (CoAP-DATA) +----------+ SMPP +-----+ (SMS) +------+ 195 | | | SMS | SS7 |SMS-C| | | 196 | A | ----------> | Service | ------> | / | ---------> | B | 197 | (IP) | <---------- | Provider | <------ | HLR | <--------- |(cell)| 198 +------+ HTTP-RES +----------+ +-----+ CoAP-RES +------+ 199 (CoAP-DATA) (SMS) 201 Figure 3: IP and Cellular Communication (using an SMS Service 202 Provider) 204 2.3. MO Scenarios 206 A mobile cellular terminal and an IP host communicate by exchanging 207 CoAP Request and Response. The mobile cellular terminal sends a CoAP 208 Request in a short message, which is in turn forwarded by the SMS-C 209 (e.g. with Short Message Peer-to-Peer (SMPP [smpp]), Computer 210 Interface to Message Distribution (CIMD [cimd]), Universal Computer 211 Protocol/External Machine Interface (UCP/EMI [ucp])) as depicted in 212 Figure 4). This scenario can be a fall-back for mobile-originating 213 communication, when IP connectivity cannot be setup (e.g. due to 214 missing coverage). 216 CoAP-REQ CIMD 217 +------+ (SMS) +-------+ SMPP +------+ 218 | A | --------> | SMS-C | ---------> | B | 219 |(cell)| <-------- | | <--------- | (IP) | 220 +------+ CoAP-RES +-------+ +------+ 221 (SMS) 223 Figure 4: Cellular and IP Communication 225 There are service providers offering SMS delivery and notification 226 using an HTTP/REST interface (depicted in Figure 5). 228 CoAP-REQ CIMD HTTP-REQ 229 +------+ (SMS) +-------+ SMPP +----------+ (CoAP-DATA) +----+ 230 | | | SMS-C | SS7 | SMS | | | 231 | A | ---------> | / | -----> | Service | ----------> | B | 232 |(cell)| <--------- | HLR | <----- | Provider | <---------- |(IP)| 233 +------+ CoAP-RES +-------+ +----------+ HTTP-RES +----+ 234 (SMS) (CoAP-DATA) 236 Figure 5: IP and Cellular Communication (using an SMS Service 237 Provider) 239 3. Message Exchanges 241 3.1. Message Exchange for SMS in a Cellular-To-Cellular Mobile- 242 Originated and Mobile-Terminated Scenario 244 The CoAP Client works as a Mobile Station to send the short message, 245 and the CoAP Server works as another Mobile Station to receive the 246 short message. All short messages are stored and forwarded by the 247 Service Center. The message exchange between the CoAP Client and the 248 CoAP Server is depicted in the figure below: 250 MS/CoAP CLIENT Service Center MS/CoAP SERVER 251 | | | 252 | ---SMS-SUBMIT---> | | 253 | <-SMS-SUBMIT-REPORT-- | | 254 | | | 255 | | --SMS-DELIVER---> | 256 | | <-SMS-DELIVER-REPORT-- | 257 | | | 258 | <-SMS-STATUS-REPORT-- | | 259 | | | 261 Figure 6: CoAP Messages over SMS 263 Note that the message exchange is just for one request message from 264 CoAP Client and CoAP Server. It includes the following steps: 266 Step 1: The CoAP Client sends a CoAP request in a SMS-SUBMIT message 267 to the Service Center. The CoAP Server address is specified as TP- 268 Destination-Address (see [ts23_040]). 270 Step 2: The Service Center returns a SMS-SUBMIT-REPORT message to the 271 CoAP Client. 273 Step 3: The Service Center stores the received SMS message and 274 forwards it to the CoAP Server, using an SMS-DELIVER message. The 275 CoAP Client address is specified as a TP Originating Address (see 276 [ts23_040]). 278 Step 4: The CoAP Server returns an SMS-DELIVER-REPORT message to the 279 Service Center. 281 Step 5: The Service Center returns the SMS-STATUS-REPORT message to 282 the CoAP Client to indicate the SMS delivery status, if required by 283 the CoAP Client. 285 Note that the SMS-STATUS-REPORT message just indicates the transport 286 layer SMS delivery status and has no relationship with the 287 confirmable message or non-confirmable message. If the CoAP Client 288 has sent a confirmable message, the CoAP Server MUST use a separate 289 SMS message to transmit the ACK. 291 4. Encoding Schemes of CoAP for SMS transport 293 Short messages can be encoded by using various alphabets: GSM 7 bit 294 default alphabet ([ts23_038]), 8 bit data alphabet, and 16 bit UCS2 295 data alphabet ([iso_ucs2]). These encodings lead to message sizes of 296 160, 140, and 70 characters, respectively. Whereas the support of 7 297 bit encoding is mandatory on a MS, the two other encodings are 298 dependent on the language that needs to be encoded, e.g. UCS2 for 299 Arabic, Chinese, Japanese, etc. Furthermore, the supported encoding 300 highly depends on the implementations of the MS itself. 302 According to [ts23_038], GSM 7 bit encoding shall be supported by all 303 MSs offering SMS services. Since not all MSs support 8 bit short 304 message encoding, the preferred encoding scheme for CoAP messages 305 over SMS is therefore 7 bit, e.g. Base64 ([RFC4648]) or SMS encoding 306 in Appendix A.1. 308 More considerations about SMS encoding can be found in Appendix A. 310 5. Message Size Implementation Considerations 312 By using 7 bit encoding, a maximum length of 160 characters is 313 allowed in one short message [ts23_038]. Consequently, the maximum 314 length for a CoAP message results in 140 bytes. 160 characters = (140 315 bytes * 8)/7. 317 Possible options for larger CoAP messages are: 319 Concatenated short messages 320 Most MSs are able to send concatenation short messages in order to 321 transmit longer messages. The total length of a concatenated 322 short message can consist of up to 255 single messages and result 323 in total length of 39015 7 bit characters or 34170 bytes. 324 Resulting from this, the maximum length of each individual message 325 reduces to 153 (160 - 7) characters (133 bytes). 327 CoAP block-wise transfer 328 According to [RFC7959], the Block Size (SZX) of block-wise 329 transfer in CoAP is represented as a three-bit unsigned integer. 330 Thus, the possible block sizes are to the power of two. (Block 331 size = 2**(SZX + 4)). Due to the limitations of 160 characters 332 (140 bytes) for one short message, the maximum value of SZX is 3 333 (Block size = 128 byte). 335 However, it is RECOMMENDED that SMS is not used to transfer very 336 large resource data using block-wise transfer. 338 6. Addressing 340 For SMS in cellular networks, the CoAP endpoints have to work with a 341 SIM (Subscriber Identity Module) card and have to be addressed by the 342 MSISDN (Mobile Station ISDN (MSISDN) number). 344 To allow the CoAP client to detect that the short message contains a 345 CoAP message, the TP-DATA-Coding-Scheme SHOULD be included. 347 7. Options 349 7.1. New Options for mixed IP operation. 351 In case a CoAP Server has more than one network interface, e.g. SMS 352 and IP, the CoAP Client might want the server to send the response 353 via an alternative transport, i.e. to it's alternative address. 354 However, that implies that the initiating CoAP Client is aware of the 355 presence of the alternative interface. For this reason the new 356 options Response-To-Uri-Host and Response-To-Uri-Port are proposed. 358 +-----+---+---+---+---+-----------------+--------+--------+---------+ 359 | No. | C | U | N | R | Name | Format | Length | Default | 360 +-----+---+---+---+---+-----------------+--------+--------+---------+ 361 | TBD | | | | | Response-To- | string | 1-270 | (none) | 362 | | | | | | Uri-Host | | B | | 363 | TBD | | | | | Response-To- | uint | 0-2 B | 5683 | 364 | | | | | | Uri-Port | | | | 365 +-----+---+---+---+---+-----------------+--------+--------+---------+ 367 Table 1: New CoAP Option Numbers 369 If the Response-To-Uri-Host is present in the request, server MUST 370 send the response to the indicated URI address, instead of the 371 client's original request URI. 373 The options SHOULD NOT be used in the response. 375 The options MUST NOT occur more than once. 377 8. URI Scheme 379 The coap:// scheme defines that a CoAP server is reachable over UDP/ 380 IP. Hence, a new URI scheme is needed for CoAP servers which are 381 reachable over SMS. 383 As proposed in [I-D.silverajan-core-coap-alternative-transports], the 384 transport information is expressed as part of the URI scheme 385 component. This is performed by minting new schemes for SMS 386 transport using the form "coap+sms", where the name of the transport 387 is clearly and unambiguously described. The endpoint identifier, 388 path and query components together with each scheme name would be 389 used to uniquely identify each resource. 391 Example of such URI : 393 o coap+sms://0015105550101/sensors/temperature 395 In the URI, 0015105550101 is a telephone subscriber number. 397 9. Transmission Parameters 399 It is RECOMMENDED to configure the RESPONSE_TIMEOUT variable for a 400 higher duration than specified in [RFC7252] for the applications 401 described here. The actual value SHOULD be chosen based on 402 experience with SMS. 404 10. Multicast 406 Multicast is not possible with SMS transports. 408 11. Security Considerations 410 It is possible that a malicious CoAP Client sends repeated requests, 411 and it may cost money for the CoAP Server to use SMS to send back 412 associated responses. To avoid this situation, the CoAP Server 413 implementation can authenticate the CoAP Client before responding to 414 the requests. For example, the CoAP Server can maintain an MSISDN 415 white list. Only the MSISDN specified in the white list will be 416 allowed to send requests. The requests from others will be ignored 417 or rejected. 419 12. IANA Considerations 421 12.1. CoAP Option Number 423 The IANA is requested to add the following option number entries to 424 the CoAP Option Number Registry: 426 +--------+----------------------+----------------------------+ 427 | Number | Name | Reference | 428 +--------+----------------------+----------------------------+ 429 | TBD | Response-To-Uri-Host | Section 2 of this document | 430 +--------+----------------------+----------------------------+ 431 | TBD | Response-To-Uri-Port | Section 2 of this document | 432 +--------+----------------------+----------------------------+ 434 12.2. URI Scheme Registration 436 According to [I-D.silverajan-core-coap-alternative-transports] this 437 document requests the registration of the Uniform Resource Identifier 438 (URI) scheme "coap+sms". The registration request complies with 439 [RFC7595]. 441 13. References 443 13.1. Normative References 445 [etsi_ts101_748] 446 ETSI, "Technical Report: Digital cellular 447 telecommunications system; Abbreviations and acronyms (GSM 448 01.04 version 8.0.0 release 1999)", 2000. 450 [iso_ucs2] 451 ISO, "ISO/IEC10646: "Universal Multiple-Octet Coded 452 Character Set (UCS)"; UCS2, 16 bit coding.", 2000. 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, 456 DOI 10.17487/RFC2119, March 1997, 457 . 459 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 460 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 461 . 463 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 464 Application Protocol (CoAP)", RFC 7252, 465 DOI 10.17487/RFC7252, June 2014, 466 . 468 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 469 and Registration Procedures for URI Schemes", BCP 35, 470 RFC 7595, DOI 10.17487/RFC7595, June 2015, 471 . 473 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 474 the Constrained Application Protocol (CoAP)", RFC 7959, 475 DOI 10.17487/RFC7959, August 2016, 476 . 478 [ts23_038] 479 ETSI 3GPP, "Technical Specification: Alphabets and 480 language-specific information (3GPP TS 23.038 version 481 11.0.0 Release 11)", 2012. 483 13.2. Informative References 485 [cimd] Nokia, "CIMD Interface Specification (SMSCDOC8000.00, 486 Nokia SMS Center 8.0)", 2005. 488 [I-D.silverajan-core-coap-alternative-transports] 489 Silverajan, B. and T. Savolainen, "CoAP Communication with 490 Alternative Transports", draft-silverajan-core-coap- 491 alternative-transports-09 (work in progress), December 492 2015. 494 [oma_lightweightm2m_ts] 495 OMA, "Lightweight Machine to Machine Technical 496 Specification", 2013. 498 [RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses", 499 RFC 1924, DOI 10.17487/RFC1924, April 1996, 500 . 502 [smpp] SMPP Developers Forum, "Short Message Peer to Peer 503 Protocol Specification v3.4 Issue 1.2", 1999. 505 [ts23_040] 506 3GPP, "Technical realization of the Short Message Service 507 (SMS)", 3GPP-23.040 a00, March 2011. 509 [ts23_682] 510 ETSI 3GPP, "Technical Specification Group Services and 511 System Aspects; Architecture Enhancements to facilitate 512 communications with Packet Data Networks and Applications; 513 (Release 11)", 2012. 515 [ts23_888] 516 ETSI 3GPP, "Technical Specification Group Services and 517 System Aspects; System Improvements for Machine-Type 518 Communications; (3GPP TR 23.888 version 1.6.0, Release 519 11)", 2011. 521 [ucp] Vodafone, "Short Message Service Centre (SMSC) External 522 Machine Interface (EMI) Description Version 4.3d", 2011. 524 Appendix A. SMS encoding 526 For use in SMS applications, CoAP messages can be transferred using 527 SMS binary mode. However, there is operational experience showing 528 that some environments cannot successfully send a binary mode SMS. 530 For transferring SMS in character mode (7-bit characters), 531 base64-encoding [RFC4648] is an obvious choice. 3 bytes of message 532 (24 bits) turn into 4 characters, which consume 28 bits. The overall 533 overhead is approximately 17 %; the maximum message size is 120 bytes 534 (160 SMS characters). 536 If a more compact encoding is desired, base85 encoding could be 537 employed (however, probably not the version defined in [RFC1924] -- 538 instead, the version used in tools such as btoa and PDF should be 539 chosen). However, this requires division operations. Also, the 540 base85 character set includes several characters that cannot be 541 transferred in a single 7-bit unit in SMS and/or are known to cause 542 operational problems. A modified base85 character set can be defined 543 to solve the latter problem. 4 bytes of message (32 bits) turn into 544 5 characters, which consume 35 bits. The overall overhead is 545 approximately 9.3 %; the resulting maximum message size is 128 bytes 546 (160 SMS characters). 548 Base64 and base85 do not make use of the fact that much CoAP data 549 will be ASCII-based. Therefore, we define the following ASCII- 550 optimized SMS encoding. 552 A.1. ASCII-optimized SMS encoding 554 Not all 128 theoretically possible SMS characters are operationally 555 free of problems. We therefore define: 557 Shunned code characters: @ sign, as it maps to 0x00 559 LF and CR signs (0x0A, 0x0D) 561 uppercase C cedilla (0x09), as it is often mistranslated in 562 gateways 564 ESC (0x1B), as it is used in certain character combinations only 566 Some ASCII characters cannot be transferred in the base SMS character 567 set, as their code positions are taken by non-ASCII characters. 568 These are simply encoded with their ASCII code positions, e.g., an 569 underscore becomes a section mark (even though underscore has a 570 different code position in the SMS character set). 572 Equivalently translated input bytes: $, @, [, \, ], ^, _, `, {, |, 573 }, ~, DEL 575 In other words, bytes 0x20 to 0x7F are encoded into the same code 576 positions in the 7-bit character set. 578 Out of the remaining code characters, the following SMS characters 579 are available for encoding: 581 Non-equivalently translated (NET) code characters: 0x01 to 0x08, (8 582 characters) 584 0x0B, 0x0C, (2 characters) 586 0x0E to 0x1A, (13 characters) 588 0x1C to 0x1F, (4 characters) 590 Of the 27 NET code characters, 18 are taken as prefix characters (see 591 below), and 8 are defined as directly translated characters: 593 Directly translated bytes: Equivalently translated input bytes are 594 represented as themselves 596 0x00 to 0x07 are represented as 0x01 to 0x08 598 This leaves 0x08 to 0x1F and 0x80 to 0xFF. Of these, the bytes 0x80 599 to 0x87 and 0xA0 to 0xFF are represented as the bytes 0x00 to 0x07 600 (represented by characters 0x01 to 0x08) and 0x20 to 0x7F, with a 601 prefix of 1 (see below). The characters 0x08 to 0x1F are represented 602 as the characters 0x28 to 0x3F with a prefix of 2 (see below). The 603 characters 0x88 to 0x9F are represented as the characters 0x48 to 604 0x5F with a prefix of 2 (see below). (Characters 0x01 to 0x08, 0x20 605 to 0x27, 0x40 to 0x47, and 0x60 to 0x7f with a prefix of 2 are 606 reserved for future extensions, which could be used for some 607 backreferencing or run-length compression.) 609 Bytes that do not need a prefix (directly translated bytes) are sent 610 as is. Any byte that does need a prefix (i.e., 1 or 2) is preceded 611 by a prefix character, which provides a prefix for this and the 612 following two bytes as follows: 614 +------+-----+---+------+-----+ 615 | char | pfx | . | char | pfx | 616 +------+-----+---+------+-----+ 617 | 0x0B | 100 | . | 0x15 | 200 | 618 | 0x0C | 101 | . | 0x16 | 201 | 619 | 0x0E | 102 | . | 0x17 | 202 | 620 | 0x0F | 110 | . | 0x18 | 210 | 621 | 0x10 | 111 | . | 0x19 | 211 | 622 | 0x11 | 112 | . | 0x1A | 212 | 623 | 0x12 | 120 | . | 0x1C | 220 | 624 | 0x13 | 121 | . | 0x1D | 221 | 625 | 0x14 | 122 | . | 0x1E | 222 | 626 +------+-----+---+------+-----+ 628 Table 2: SMS prefix character assignment 630 (This leaves one non-shunned character, 0x1F, for future extension.) 632 The coding overhead of this encoding for random bytes is similar to 633 Base85, without the need for a division/multiplication. For bytes 634 that are mostly ASCII characters, the overhead can easily become 635 negative. (Conversely, for bytes that for some reason are more 636 likely to be non-ASCII than in a random sequence of bytes, the 637 overhead becomes greater.) 639 So, for instance, for the CoAP message in Figure 7: 641 ver tt code mid 642 1 ack 2.05 17033 643 content_type 40 644 token sometok 645 3c 2f 3e 3b 74 69 74 6c 65 3d 22 47 65 6e 65 72 |;title="Gener| 646 61 6c 20 49 6e 66 6f 22 3b 63 74 3d 30 2c 3c 2f |al Info";ct=0,;if="clock"| 648 3b 72 74 3d 22 54 69 63 6b 73 22 3b 74 69 74 6c |;rt="Ticks";titl| 649 65 3d 22 49 6e 74 65 72 6e 61 6c 20 43 6c 6f 63 |e="Internal Cloc| 650 6b 22 3b 63 74 3d 30 2c 3c 2f 61 73 79 6e 63 3e |k";ct=0,| 651 3b 63 74 3d 30 |;ct=0 | 653 Figure 7: CoAP response message as captured and decoded 655 The 116 byte unencoded message is shown as ASCII characters in 656 Figure 8 (\xDD stands for the byte with the hex digits DD): 658 bEB\x89\x11(\xA7sometok;title="General Info";ct=0, 659 ;if="clock";rt="Ticks";title="Internal Clock";ct=0,;ct=0 661 Figure 8: CoAP response message shown as unencoded characters 663 The only non-ASCII characters in this example are in the beginning of 664 the message. According to the translation instructions above, the 665 four bytes: 667 89 11 ( A7 669 need the prefixes: 671 2 2 0 1 673 As each prefix character always covers three unencoded bytes, we need 674 the prefix characters for 220 and 100, which are \x1C and \x0B, 675 respectively (Table 2). 677 The equivalent SMS encoding is shown as equivalent-coded SMS 678 characters in Figure 9 (7 bits per character, \x1C is the 220 prefix 679 and \x0B is the 100 prefix, the rest is shown in equivalent 680 encoding), adding two characters of prefix overhead, for a total 681 length of 118 7-bit characters or 104 (103.25 plus padding) bytes: 683 bEB\x1CI1(\x0B'sometok;title="General Info";ct=0, 684 ;if="clock";rt="Ticks";title="Internal Clock";ct=0,;ct=0 686 Figure 9: CoAP response message shown as SMS-encoded characters 688 Appendix B. Changelog 690 RFC editor: please remove this appendix. 692 Changed from draft-05 to draft-06: 694 o Update references and addresses 696 o Integrate relevant text from coap-misc as an appendix. 698 o Section 2 & 3 are merged to section 1 700 Changed from draft-04 to draft-05: 702 o Removed reference to USSD. 704 o Updated reference to RFC7252 and 3GPP specs. 706 o Updated Options. 708 o Adapted URI scheme. 710 Changed from draft-03 to draft-04: 712 o Removed USSD and GPRS related parts. 714 o Removed section 5: Examples 716 o Removed section 14: Proxying Considerations 718 o Added more block size considerations. 720 o Added more concatenated SMS considerations. 722 o Rewrote encoding scheme section; 7 bit encoding only. 724 Changed from draft-02 to draft-03: 726 o Added reference to OMA LightweightM2M Technical Specification in 727 "Motivation" section. 729 o Chose CoAP option numbers and updated the option number table to 730 meet draft-ietf-core-coap-13. 732 Changed from draft-01 to draft-02: 734 o Added security considerations: Transport and Object Security. 735 Section 11 737 o Reply-To-* changed to Response-To-*. Section 12 739 o Added URI scheme. 741 o Added possible CON/NON/ACK interactions. 743 o Added possible M2M proxy scenarios. 745 o Added reference to bormann-coap-misc for other SMS encoding. 746 Section 4 748 o Updated requirements on Uri-Host and Uri-Port for coap+tel://. 750 o Chose CoAP option numbers and updated the option number table to 751 meet draft-ietf-core-coap-10. /> 753 o Added an IANA registration for the URI scheme. Section 12.2 755 Acknowledgements 757 This document is partly based on research for the research project 758 'The Intelligent Container' which is supported by the Federal 759 Ministry of Education and Research, Germany, under reference number 760 01IA10001. 762 The authors of this draft would like to thank Bert Greevenbosch, 763 Marcus Goetting, Nils Schulte and Klaus Hartke for the discussions on 764 the topic and the reviews of this document. 766 Contributors 768 Appendix A has been contributed by Carsten Bormann. 770 Carsten Bormann 771 Universitaet Bremen TZI 772 Postfach 330440 773 Bremen D-28359 774 Germany 776 Phone: +49-421-218-63921 777 EMail: cabo@tzi.org 779 Authors' Addresses 780 Koojana Kuladinithi (editor) 781 ComNets, Hamburg University of Technology 782 Am Schwarzenberg-Campus 3 783 Hamburg 21073 784 Germany 786 Phone: +49 40 428 783533 787 Email: koojana.kuladinithi@tuhh.de 789 Markus Becker 790 Tridonic GmbH & Co KG 791 Faerbergasse 15 792 Dornbirn 6851 793 Austria 795 Phone: +43 5572 395 45637 796 Email: markus.becker@tridonic.com 798 Kepeng LI 799 Alibaba Group 800 Wenyixi Road, Yuhang District 801 Hangzhou, Zhejiang 311121 802 China 804 Email: kepeng.lkp@alibaba-inc.com 806 Thomas Poetsch 807 New York University Abu Dhabi 808 P.O. Box 129188 809 Abu Dhabi 129188 810 United Arab Emirates 812 Phone: +971 2 628 5069 813 Email: thomas.poetsch@nyu.edu