CoRE Working Group M.B. Becker, Ed.
Internet-Draft K.K. Kuladinithi
Intended status: Informational T.P. Pötsch
Expires: April 26, 2012 ComNets, TZI, University Bremen
October 24, 2011

Transport of CoAP over SMS and GPRS


The Short Message Service (SMS) of mobile cellular networks is frequently used in Machine-To-Machine (M2M) communications, such as for telematic devices. The service offers small packet sizes and high delays just as other typical low-power and lossy networks (LLNs), i.e. 6LoWPANs. The design of the Constrained Application Protocol (CoAP), that took the limitations of LLNs into account, is thus also applicable to telematic M2M devices. The adaption of CoAP to the SMS transport mechanism is described in this document.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 26, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

This specification details the usage of the Constrained Application Protocol on the Short Message Service of mobile cellular networks.

1.1. Scenarios

+------+  (SMS)   +------+
|  A   | -------> |  B   |
|(cell)| <------- |(cell)|
+------+ CoAP-RES +------+
+------+  (SMS)   +------+
|  A   | -------> |  B   |
|(cell)| <------- |(cell)|
+------+ CoAP-RES +------+
          UCP/EMI            CoAP-REQ
+------+   SMPP    +-------+   (SMS)  +------+
|  A   | --------> | SMS-C | -------> |  B   |
| (IP) | <-------- |       | <------- |(cell)|
+------+           +-------+ CoAP-RES +------+
          UCP/EMI            CoAP-REQ
+------+   SMPP    +-------+   (SMS)  +------+
|  A   | --------> | SMS-C | -------> |  B   |
| (IP) |           |       |          |(cell)|
+------+           +-------+          +------+
   ^                                     |
   |               +-------+             |
   |               | GGSN  |             |
   +-------------- |       | <-----------+
                   +-------+    CoAP-RES
          HTTP-REQ                 UCP/EMI         CoAP-REQ
+------+ (CoAP-DATA) +-----------+  SMPP   +-----+   (SMS)  +------+
|  A   | ----------> |SMS Service| ------> |SMS-C| -------> |  B   |
| (IP) | <---------- |Provider   | <------ |     | <------- |(cell)|
+------+  HTTP-RES   +-----------+         +-----+ CoAP-RES +------+
         (CoAP-DATA)                                 (SMS)

Figure 1 to Figure 5 show various applicable usage scenarios of CoAP in M2M communications. Two mobile cellular terminals communicate by exchanging CoAP Request and Response embedded into SMS PDUs (depicted in Figure 1). Figure 2). [cimd]), Universal Computer Protocol/External Machine Interface (UCP/EMI [ucp]), Short Message Peer-to-Peer (SMPP [smpp]) ) to submit an SMS for delivery, which contains the CoAP Request (depicted in Figure 3). Figure 4). Figure 5). Figure 1, Figure 3 and Figure 5), i.e.\ only SMS transport.

1.2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. Encoding of CoAP for SMS transport

The content of SMS can be coded in 7, 8 or 16 bit characters [3gpp_ts23.038]. The advantages and disadvantages are:

  1. 7 bit encoding: Sending 7 bit encoded SMS possible with almost all devices. CoAP binary data needs to be re-encoded, possibly with Base64 RFC 4648 [RFC4648].
  2. 8 bit encoding: CoAP binary data does not need to be re-encoded. Not all telematic devices support 8 bit SMS encoding.
  3. 16 bit encoding: CoAP binary data needs to be re-encoded. Not all telematic devices support 16 bit SMS encoding.

The currently safest solution is to use 7 bit encoded SMS including Base64 encoded CoAP payload.

3. Message Size Implementation Considerations

Using 7 bit encoding 160 characters are allowed in 1 SMS, while using 8 bit encoding 140 characters are allowed. [3gpp_ts23.038]

Possible options for larger CoAP messages are:

  1. Multiple SMS concatenation
  2. CoAP Block [I-D.ietf-core-block]

4. Options

Uri-Host and Uri-Port options MUST NOT be included in the CoAP header. End-points receiving CoAP messages over SMS with such options MUST behave as specified in [I-D.ietf-core-coap].

Open question: Is the introduction of a new CoAP option Reply-To-Uri-Host necessary, if the server should use the GPRS transport for the Response? This relates to Figure 2 and Figure 4.

New CoAP Option Numbers
Number C/E Name Format Length Default
17 Critical Reply-To-Uri-Host string 1-270 B (none)
19 Critical Reply-To-Uri-Port uint 0-2 B (none)

5. Protocol Constants

The RESPONSE_TIMEOUT variable SHOULD be configured for a higher duration than specified in [I-D.ietf-core-coap], i.e. 10 s.

6. Multicast

Multicast MUST not be used with the SMS transport.

7. Proxying Considerations

TBD (Proxying into an IPv6/v4 network (e.g. a 6LoWPAN network) possible?)

8. SMS URI scheme for link-format

Open question: Make use of RFC5724 SMS URI scheme?

9. Acknowledgements

This document is based on research for the research project 'The Intelligent Container' which is supported by the Federal Ministry of Education and Research, Germany, under reference number 01IA10001.

10. IANA Considerations

This memo includes no request to IANA.

11. Security Considerations

This presents no security considerations beyond those in section 10 of the base CoAP specification [I-D.ietf-core-coap].

12. References

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[I-D.ietf-core-coap] Shelby, Z, Hartke, K, Bormann, C and B Frank, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-08, October 2011.
[I-D.ietf-core-block] Bormann, C and Z Shelby, "Blockwise transfers in CoAP", Internet-Draft draft-ietf-core-block-04, July 2011.
[3gpp_ts23.038] ETSI 3GPP, "Technical Specification: Alphabets and language-specific information (3GPP TS 23.038 version 10.0.0 Release 10)", 2011.

12.2. Informative References

[cimd] Nokia, "CIMD Interface Specification (SMSCDOC8000.00, Nokia SMS Center 8.0)", 2005.
[ucp] Vodafone, "Short Message Service Centre (SMSC) External Machine Interface (EMI) Description Version 4.3d", 2011.
[smpp] SMPP Developers Forum, "Short Message Peer to Peer Protocol Specification v3.4 Issue 1.2", 1999.

Authors' Addresses

Markus Becker editor ComNets, TZI, University Bremen Bibliothekstrasse 1 Bremen, 28359 Germany Phone: +49 421 218 62379 EMail:
Koojana Kuladinithi ComNets, TZI, University Bremen Bibliothekstrasse 1 Bremen, 28359 Germany Phone: +49 421 218 62382 EMail:
Thomas Pötsch ComNets, TZI, University Bremen Bibliothekstrasse 1 Bremen, 28359 Germany Phone: +49 421 218 62379 EMail: