CoRE Working Group M. Becker, Ed.
Internet-Draft K. Li
Intended status: Informational Huawei Technologies
Expires: September 01, 2012 K. Kuladinithi
ComNets, TZI, University Bremen
T. Pötsch
ComNets, TZI, University Bremen
March 02, 2012

Transport of CoAP over SMS, USSD and GPRS


The Short Message Service (SMS) and Unstructured Supplementary Service Data (USSD) 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 adaptation of CoAP to the SMS or USSD transport mechanisms and the combination with IP transported over cellular networks 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 September 01, 2012.

Copyright Notice

Copyright (c) 2012 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 (SMS) or Unstructured Supplementary Service Data (USSD) of mobile cellular networks.

1.1. Motivation

In some M2M environments, internet connectivity is not supported by the constrained end-points, but a cellular network connection is supported instead. Internet connectivity might also be switched off for power saving reasons or the cellular coverage does not allow for Internet connectivity. In these situations, SMS and USSD will be supported, instead of UDP/IP over GPRS, HSPA or LTE.

In Open Mobile Alliance (OMA), there is a new approved work item named "the Lightweight M2M Protocol", which aims at identifying requirements and defining protocols for M2M applications in cellular networks.

In 3GPP, SMS is identified as the transport protocol for small data transmissions (See [3gpp_ts23_888] for Key Issue on Machine Type Communication (MTC) Device Trigger and the proposed solutions in Sections 6.2, 6.42, 6.44, 6.48, 6.52, 6.60, and 6.61). In [3gpp_ts23_682] 'Architecture Enhancements to facilitate communications with Packet Data Networks and Applications' SMS is at the moment the only Trigger Delivery (Trigger Delivery using T4). USSD does seem to be in standardisation as a solution for MTC Device Trigger.

M2M protocols using SMS, e.g. for telematics, are using mostly various diverse proprietary and closed binary protocols with limited publicly available documentation at the moment.

USSD is a very basic service in mobile networks which uses fewer network components to provide a service similar to SMS. This makes USSD very cheap for mobile network operators and chipset manufactures as they do not have to provide additional infrastructure. This is why USSD is from a technical point of view supported by all handsets and other mobile devices in all networks.

Where SMS are normally stored in the SMS-C before the actual delivery takes place, USSD messages are not stored but delivered immediately. If it is impossible to deliver a USSD message within the first attempt, delivery fails. This could be a problem, but could also be seen as an advantage as long as delivery problems are covered by higher level protocols, such as CoAP. Without store-and-forward mechanisms the delivery is absolutely deterministic. There is only "success" or "failure" and no "wait a minute".

2. Terminology

The terms CoAP Server and CoAP Client are used synonymously to Server and Client as specified in the terminology section of [I-D.ietf-core-coap].

3. 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].

4. Scenarios

Several scenarios are presented first for M2M communications with CoAP. First Mobile-Originating Mobile-Terminating (MO-MT) scenarios are presented, where both CoAP endpoints are in devices in a cellular network. Next, Mobile-Terminating (MT) scenarios are detailed, where only the CoAP server is in a cellular network. Finally, Mobile-Originating (MO) scenarios where the CoAP client is in the cellular network.

4.1. MO-MT Scenarios

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

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

4.2. MT Scenarios

           CIMD               CoAP-REQ
+------+   SMPP    +-------+    (SMS)   +------+
|  A   | --------> | SMS-C | ---------> |  B   |
| (IP) | <-------- |       | <--------- |(cell)|
+------+           +-------+  CoAP-RES  +------+
           CIMD               CoAP-REQ
+------+   SMPP    +-------+    (SMS)   +------+
|  A   | --------> | SMS-C | ---------> |  B   |
| (IP) |           |       |            |(cell)|
+------+           +-------+            +------+
   ^                                       |
   |               +-------+               |
   |               | GGSN  |               |
   +-------------- |       | <-------------+
        CoAP-RES   +-------+    CoAP-RES
          (IP)                   (GPRS)
          HTTP-REQ                 CIMD            CoAP-REQ
+------+ (CoAP-DATA) +----------+  SMPP   +-----+ (SMS/USSD) +------+
|      |             | SMS/USSD |  SS7    |SMS-C|            |      |
|  A   | ----------> | Service  | ------> |  /  | ---------> |  B   |
| (IP) | <---------- | Provider | <------ | HLR | <--------- |(cell)|
+------+  HTTP-RES   +----------+         +-----+  CoAP-RES  +------+
         (CoAP-DATA)                              (SMS/USSD)

An IP host and a mobile cellular terminal communicate by exchanging CoAP Request and Response. The IP host uses protocols offered by the SMS-C (e.g. Short Message Peer-to-Peer (SMPP [smpp]), Computer Interface to Message Distribution (CIMD [cimd]), Universal Computer Protocol/External Machine Interface (UCP/EMI [ucp])) to submit an SMS for delivery, which contains the CoAP Request (depicted in Figure 3). Figure 4). Figure 5).

4.3. MO Scenarios

          CoAP-REQ              CIMD
+------+   (SMS)   +-------+    SMPP    +------+
|  A   | --------> | SMS-C | ---------> |  B   |
|(cell)| <-------- |       | <--------- | (IP) |
+------+  CoAP-RES +-------+            +------+
          CoAP-REQ             CIMD                HTTP-REQ
+------+ (SMS/USSD) +-------+  SMPP  +----------+ (CoAP-DATA) +----+
|      |            | SMS-C |  SS7   | SMS/USSD |             |    |
|  A   | ---------> |   /   | -----> | Service  | ----------> | B  |
|(cell)| <--------- |  HLR  | <----- | Provider | <---------- |(IP)|
+------+  CoAP-RES  +-------+        +----------+  HTTP-RES   +----+
         (SMS/USSD)                               (CoAP-DATA)
+------+  CoAP-REQ +-------+            +------+
|  A   | --------> | GGSN  | ---------> |  B   |
|(cell)| <-------- |       | <--------- | (IP) |
+------+  CoAP-RES +-------+            +------+

A mobile cellular terminal and an IP host communicate by exchanging CoAP Request and Response. The mobile cellular terminal sends a CoAP Request in an SMS, which is in turn forwarded by the SMS-C (e.g. with Short Message Peer-to-Peer (SMPP [smpp]), Computer Interface to Message Distribution (CIMD [cimd]), Universal Computer Protocol/External Machine Interface (UCP/EMI [ucp])) as depicted in Figure 6). This scenario can be a fall-back for mobile-originating communication, when IP connectivity cannot be setup (e.g. due to missing coverage). Figure 7). [I-D.ietf-core-coap] (depicted in Figure 8.

5. Message Exchanges

5.1. Message Exchange for SMS in a Cellular-To-Cellular Mobile-Originated and Mobile-Terminated Scenario

The CoAP Client works as a Mobile Station to send the SMS message, and the CoAP Server works as another Mobile Station to receive the SMS message. All the SMS messages are stored and forwarded by the Service Center. The message exchange between the CoAP Client and the CoAP Server is depicted in the figure below:

 MS/CoAP CLIENT        Service Center          MS/CoAP SERVER
     |                       |                        |
     |   ---SMS-SUBMIT--->   |                        |
     | <-SMS-SUBMIT-REPORT-- |                        |
     |                       |                        |
     |                       |    --SMS-DELIVER--->   |
     |                       | <-SMS-DELIVER-REPORT-- |
     |                       |                        |
     | <-SMS-STATUS-REPORT-- |                        |
     |                       |                        |

Note that the message exchange is just for one request message from CoAP Client and CoAP Server. It includes the following steps:

Step 1: The CoAP Client sends a CoAP request in a SMS-SUBMIT message to the Service Center. The CoAP Server address is specified as TP-Destination-Address (see [3gpp_ts_23_040]).

Step 2: The Service Center returns a SMS-SUBMIT-REPORT message to the CoAP Client.

Step 3: The Service Center stores the received SMS message and forwards it to the CoAP Server, using an SMS-DELIVER message. The CoAP Client address is specified as a TP Originating Address (see [3gpp_ts_23_040]).

Step 4: The CoAP Server returns an SMS-DELIVER-REPORT message to the Service Center.

Step 5: The Service Center returns the SMS-STATUS-REPORT message to the CoAP Client to indicate the SMS delivery status, if required by the CoAP Client.

Note that the SMS-STATUS-REPORT message just indicates the transport layer SMS delivery status and has no relationship with the confirmable message or non-confirmable message. If the CoAP Client has sent a confirmable message, the CoAP Server MUST use a separate SMS message to transmit the ACK.

5.2. Message Exchange for USSD

The message exchange for USSD is shown simplified in Figure 10 and Figure 11. The communication between MS, MSC, VLR, HLR, and USSD-GW is based on SS7 signalling and the communication between USSD-GW is based on IP. Messages ending with _RPC are Remote Procedure Calls (e.g. REST); messages without _RPC are SS7 signalling.

Message Sequence Charts with more details can be found in [3gpp_ts23_090].

     |                    |                        |
     | ---USSD_REQUEST--> |                        |
     |                    |                        |
     |                    | ---USSD_REQUEST_RPC--> |
     |                    | <--USSD_RESPONSE_RPC-- |
     |                    |                        |
     | <--USSD_RESPONSE-- |                        |
     |                    |                        |

In Figure 10 the message sequence chart for the USSD transport (Mobile Originated) is shown.

     |                    |                        |
     |                    | <--USSD_REQUEST_RPC--- |
     |                    |                        |
     | <--USSD_REQUEST--- |                        |
     | ---USSD_RESPONSE-> |                        |
     |                    |                        |
     |                    | ---USSD_RESPONSE_RPC-> |
     |                    |                        |

In Figure 11 the message sequence chart for the USSD transport (Mobile Terminated) is shown.

6. Encoding of CoAP for non-IP transports

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

6.2. Encoding of CoAP for USSD transport

The encoding of USSD data is identical to the encoding of SMS.

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

It is RECOMMENDED that SMS is not used to transfer very large resource data using Blocks.

There is no possibility to concatenate messages with USSD, thus the only option would be CoAP Block is necessary.

8. Addressing

For SMS in cellular networks, the CoAP endpoints have to work with a SIM (Subscriber Identity Module) card and have to be addressed by the MSISDN (Mobile Station ISDN (MSISDN) number).

To allow the CoAP client to detect that the SMS message contains a CoAP message, the TP-DATA-Coding-Scheme SHOULD be included.

For mobile-originated USSD the addressing is done by a so called application numbers.

9. Options

Uri-Host: The Uri-Host option SHOULD only be sent, in case of proxying. If no proxying is intended the option SHOULD NOT BE set.

Uri-Port: The Uri-Host option SHOULD only be sent, in case of proxying. If no proxying is intended the option SHOULD NOT BE set.

End-points receiving CoAP messages over SMS with such options MUST behave as specified in [I-D.ietf-core-coap].

9.1. New Options for mixed IP/non-IP operation.

When CoAP should be used in mixed IP and non-IP mode (e.g. SMS/USSD and GPRS as in Figure 2 and Figure 4) the server needs to be informed about the client's other address that should be used for the CoAP response. For this reason the new options Reply-To-Uri-Host and Reply-To-Uri-Port are proposed.

OPEN QUESTION: Are CoAP user option numbers applicable here?

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

10. Protocol Constants

It is RECOMMENDED to configure the RESPONSE_TIMEOUT variable for a higher duration than specified in [I-D.ietf-core-coap] for the applications described here. The actual value SHOULD be chosen based on experience with SMS, USSD and GPRS.

11. Multicast

Multicast MUST NOT be used with the SMS and USSD transports.

12. Proxying Considerations

In case of non-IP transport, several use cases might arise for proxies:

13. IANA Considerations

This memo currently includes no request to IANA. If Reply-To-Uri-Host and Reply-To-Uri-Port are deemed useful and decision is taken not to have CoAP user options, it might include IANA requests.

14. Security Considerations

Security mechanisms defined in [3gpp_ts23_888] are used to guarantee transport security.

It is possible that a malicious CoAP Client sends repeated requests, and it may cost money for the CoAP Server to use SMS to send back associated responses. To avoid this situation, the CoAP Server implementation can authenticate the CoAP Client before responding to the requests. For example, the CoAP Server can maintain a MSISDN white list. Only the MSISDN specified in the white list will be allowed to send requests. The requests from others will be ignored or rejected.

15. Acknowledgements

This document is partly 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.

The authors of this draft would like to thank Bert Greevenbosch, Marcus Götting and Nils Schulte for the discussion.

16. References

16.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-07, January 2012.
[3gpp_ts23_038] ETSI 3GPP, "Technical Specification: Alphabets and language-specific information (3GPP TS 23.038 version 10.0.0 Release 10)", 2011.
[3gpp_ts23_090] ETSI 3GPP, "Technical Specification: Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Unstructured Supplementary Service Data (USSD); Stage 2 (3GPP TS 23.090 version 10.0.0 Release 10)", 2011.

16.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.
[3gpp_ts23_888] ETSI 3GPP, "Technical Specification Group Services and System Aspects; System Improvements for Machine-Type Communications; (3GPP TR 23.888 version 1.6.0, Release 11)", 2011.
[3gpp_ts_23_040] 3GPP, "Technical realization of the Short Message Service (SMS)", 3GPP-23.040 a00, Mar 2011.
[3gpp_ts23_682] ETSI 3GPP, "Technical Specification Group Services and System Aspects; Architecture Enhancements to facilitate communications with Packet Data Networks and Applications; (Release 11)", 2012.

Authors' Addresses

Markus Becker editor ComNets, TZI, University Bremen Bibliothekstrasse 1 Bremen, 28359 Germany Phone: +49 421 218 62379 EMail:
Kepeng Li Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P. R. China Phone: +86-755-28974289 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: