| CoRE | M. Becker, Ed. |
| Internet-Draft | ComNets, TZI, University Bremen |
| Intended status: Standards Track | K. Li |
| Expires: February 9, 2015 | Huawei Technologies |
| K. Kuladinithi | |
| T. Pötsch | |
| ComNets, TZI, University Bremen | |
| August 8, 2014 |
Transport of CoAP over SMS
draft-becker-core-coap-sms-gprs-05
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) [RFC7252], that took the limitations of LLNs into account, is thus also applicable to other transports. The adaptation of CoAP to SMS transport mechanisms is described in this document.
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 February 9, 2015.
Copyright (c) 2014 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.
This specification details the usage of the Constrained Application Protocol on the Short Message Service (SMS) of mobile cellular networks.
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 will be supported, instead of UDP/IP over General Packet Radio Service (GPRS), High Speed Packet Access (HSPA) or Long Term Evolution (LTE) networks.
In 3GPP, SMS is identified as the transport protocol for small data transmissions (See [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 [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).
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.
In Open Mobile Alliance (OMA) LightweightM2M technical specification [oma_lightweightm2m_ts], SMS is identified as an alternative transport for CoAP messages.
This document uses the following terminology:
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].
Several scenarios are presented first for M2M communications with CoAP over SMS. 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.
CoAP-REQ CoAP-REQ
+------+ (SMS) +-------+ (SMS) +------+
| A | --------> | SMS-C | -------> | B |
|(cell)| <-------- | | <------- |(cell)|
+------+ CoAP-RES +-------+ CoAP-RES +------+
(SMS) (SMS)
Figure 1: Cellular and Cellular Communication (only SMS-based)
Two mobile cellular terminals communicate by exchanging a CoAP Request and Response embedded into short message protocol data units (PDUs) (depicted in Figure 1). Both terminals are connected via a Short Message Service Centre (SMS-C).
CIMD CoAP-REQ
+------+ SMPP +-------+ (SMS) +------+
| A | --------> | SMS-C | ---------> | B |
| (IP) | <-------- | | <--------- |(cell)|
+------+ +-------+ CoAP-RES +------+
(SMS)
Figure 2: IP and Cellular Communication
HTTP-REQ CIMD CoAP-REQ
+------+ (CoAP-DATA) +----------+ SMPP +-----+ (SMS) +------+
| | | SMS | SS7 |SMS-C| | |
| A | ----------> | Service | ------> | / | ---------> | B |
| (IP) | <---------- | Provider | <------ | HLR | <--------- |(cell)|
+------+ HTTP-RES +----------+ +-----+ CoAP-RES +------+
(CoAP-DATA) (SMS)
Figure 3: IP and Cellular Communication (using an SMS Service Provider)
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 a short message for delivery, which contains the CoAP Request (depicted in Figure 2). Figure 3).
CoAP-REQ CIMD
+------+ (SMS) +-------+ SMPP +------+
| A | --------> | SMS-C | ---------> | B |
|(cell)| <-------- | | <--------- | (IP) |
+------+ CoAP-RES +-------+ +------+
(SMS)
Figure 4: Cellular and IP Communication
CoAP-REQ CIMD HTTP-REQ
+------+ (SMS) +-------+ SMPP +----------+ (CoAP-DATA) +----+
| | | SMS-C | SS7 | SMS | | |
| A | ---------> | / | -----> | Service | ----------> | B |
|(cell)| <--------- | HLR | <----- | Provider | <---------- |(IP)|
+------+ CoAP-RES +-------+ +----------+ HTTP-RES +----+
(SMS) (CoAP-DATA)
Figure 5: IP and Cellular Communication (using an SMS Service Provider)
A mobile cellular terminal and an IP host communicate by exchanging CoAP Request and Response. The mobile cellular terminal sends a CoAP Request in a short message, 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 4). This scenario can be a fall-back for mobile-originating communication, when IP connectivity cannot be setup (e.g. due to missing coverage). Figure 5).
The CoAP Client works as a Mobile Station to send the short message, and the CoAP Server works as another Mobile Station to receive the short message. All short 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-- | |
| | |
Figure 6: CoAP Messages over SMS
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 [ts23_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 [ts23_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.
Short messages can be encoded by using various alphabets: GSM 7 bit default alphabet ([ts23_038]), 8 bit data alphabet, and 16 bit USC2 data alphabet ([iso_ucs2]). These encodings lead to message sizes of 160, 140, and 70 characters, respectively. Whereas the support of 7 bit encoding is mandatory on a MS, the two other encodings are dependent on the language that needs to be encoded, e.g. USC2 for Arabic, Chinese, Japanese, etc. Furthermore, the supported encoding highly depends on the implementations of the MS itself.
According to [ts23_038], GSM 7 bit encoding shall be supported by all MSs offering SMS services. Since not all MSs support 8 bit short message encoding, the prefered encoding scheme for CoAP messages over SMS is therefore 7 bit, e.g. Base64 ([RFC4648]) or SMS encoding in [I-D.bormann-coap-misc].
More considerations about SMS encoding can be found in [I-D.bormann-coap-misc].
By using 7 bit encoding, a maximum length of 160 characters is allowed in one short message [ts23_038]. Consequently, the maximum length for a CoAP message results in 140 bytes. 160 characters = (140 bytes * 8)/7.
Possible options for larger CoAP messages are:
However, it is RECOMMENDED that SMS is not used to transfer very large resource data using blockwise transfer.
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 short message contains a CoAP message, the TP-DATA-Coding-Scheme SHOULD be included.
In case a CoAP Server has more than one network interface, e.g. SMS and IP, the CoAP Client might want the server to send the response via an alternative transport, i.e. to it's alternative address. However, that implies that the initiating CoAP Client is aware of the presence of the alternative interface. For this reason the new options Response-To-Uri-Host and Response-To-Uri-Port are proposed.
| No. | C | U | N | R | Name | Format | Length | Default |
|---|---|---|---|---|---|---|---|---|
| TBD | Response-To-Uri-Host | string | 1-270 B | (none) | ||||
| TBD | Response-To-Uri-Port | uint | 0-2 B | 5683 |
If the Response-To-Uri-Host is present in the request, server MUST send the response to the indicated URI address, instead of the client's original request URI.
The options SHOULD NOT be used in the response.
The options MUST NOT occur more than once.
The coap:// scheme defines that a CoAP server is reachable over UDP/IP. Hence, a new URI scheme is needed for CoAP servers which are reachable over SMS.
As specified in [I-D.silverajan-core-coap-alternative-transports], the transport information is expressed as part of the URI scheme component. This is performed by minting new schemes for SMS transport using the form "coap+sms", where the name of the transport is clearly and unambiguously described. The endpoint identifier, path and query components together with each scheme name would be used to uniquely identify each resource.
Example of such URI :
o coap+sms://0015105550101/sensors/temperature
In the URI, 0015105550101 is a telephone subscriber number.
It is RECOMMENDED to configure the RESPONSE_TIMEOUT variable for a higher duration than specified in [RFC7252] for the applications described here. The actual value SHOULD be chosen based on experience with SMS .
Multicast is not possible with SMS transports.
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 an 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.
The IANA is requested to add the following option number entries to the CoAP Option Number Registry:
+--------+----------------------+----------------------------+ | Number | Name | Reference | +--------+----------------------+----------------------------+ | TBD | Response-To-Uri-Host | Section 2 of this document | +--------+----------------------+----------------------------+ | TBD | Response-To-Uri-Port | Section 2 of this document | +--------+----------------------+----------------------------+
According to [I-D.silverajan-core-coap-alternative-transports] this document requests the registration of the Uniform Resource Identifier (URI) scheme "coap+alt". The registration request complies with [RFC4395].
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, Nils Schulte and Klaus Hartke for the discussions on the topic and the reviews of this document.
| [cimd] | Nokia, "CIMD Interface Specification (SMSCDOC8000.00, Nokia SMS Center 8.0)", 2005. |
| [oma_lightweightm2m_ts] | OMA, "Lightweight Machine to Machine Technical Specification", 2013. |
| [smpp] | SMPP Developers Forum, "Short Message Peer to Peer Protocol Specification v3.4 Issue 1.2", 1999. |
| [ts23_040] | 3GPP, "Technical realization of the Short Message Service (SMS)", 3GPP-23.040 a00, Mar 2011. |
| [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. |
| [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. |
| [ucp] | Vodafone, "Short Message Service Centre (SMSC) External Machine Interface (EMI) Description Version 4.3d", 2011. |
Changed from draft-04 to draft-05:
Changed from draft-03 to draft-04:
Changed from draft-02 to draft-03:
Changed from draft-01 to draft-02: