Transport of CoAP over SMS and GPRS
draft-becker-core-coap-sms-gprs-00

Abstract

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 http://datatracker.ietf.org/drafts/current/.

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 (http://trustee.ietf.org/license-info) 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
• 1.1. Scenarios
• 1.2. Requirements Language
• 2. Encoding of CoAP for SMS transport
• 3. Message Size Implementation Considerations
• 4. Options
• 5. Protocol Constants
• 6. Multicast
• 7. Proxying Considerations
• 8. SMS URI scheme for link-format
• 9. Acknowledgements
• 10. IANA Considerations
• 11. Security Considerations
• 12. References
• 12.1. Normative References
• 12.2. Informative References
• Authors' Addresses

1. Introduction

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

1.1. Scenarios

         CoAP-REQ
+------+  (SMS)   +------+
|  A   | -------> |  B   |
|(cell)| <------- |(cell)|
+------+ CoAP-RES +------+
          (SMS)
            

         CoAP-REQ
+------+  (SMS)   +------+
|  A   | -------> |  B   |
|(cell)| <------- |(cell)|
+------+ CoAP-RES +------+
          (GPRS)
            

           CIMD
          UCP/EMI            CoAP-REQ
+------+   SMPP    +-------+   (SMS)  +------+
|  A   | --------> | SMS-C | -------> |  B   |
| (IP) | <-------- |       | <------- |(cell)|
+------+           +-------+ CoAP-RES +------+
                               (SMS)
            

           CIMD
          UCP/EMI            CoAP-REQ
+------+   SMPP    +-------+   (SMS)  +------+
|  A   | --------> | SMS-C | -------> |  B   |
| (IP) |           |       |          |(cell)|
+------+           +-------+          +------+
   ^                                     |
   |               +-------+             |
   |               | GGSN  |             |
   +-------------- |       | <-----------+
                   +-------+    CoAP-RES
                                (GPRS)
            

                                    CIMD
          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.

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

12.2. Informative References

Authors' Addresses