Internet DRAFT - draft-becker-core-coap-sms-gprs
draft-becker-core-coap-sms-gprs
CoRE K. Kuladinithi, Ed.
Internet-Draft ComNets, Hamburg University of Technology
Intended status: Standards Track M. Becker
Expires: August 24, 2017 Tridonic GmbH & Co KG
K. Li
Alibaba Group
T. Poetsch
New York University Abu Dhabi
February 20, 2017
Transport of CoAP over SMS
draft-becker-core-coap-sms-gprs-06
Abstract
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.
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 August 24, 2017.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kuladinithi, et al. Expires August 24, 2017 [Page 1]
Internet-Draft CoAP over SMS February 2017
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. MO-MT Scenarios . . . . . . . . . . . . . . . . . . . . . 4
2.2. MT Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
2.3. MO Scenarios . . . . . . . . . . . . . . . . . . . . . . 5
3. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Message Exchange for SMS in a Cellular-To-Cellular
Mobile-Originated and Mobile-Terminated Scenario . . . . 6
4. Encoding Schemes of CoAP for SMS transport . . . . . . . . . 7
5. Message Size Implementation Considerations . . . . . . . . . 7
6. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. New Options for mixed IP operation. . . . . . . . . . . . 8
8. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Transmission Parameters . . . . . . . . . . . . . . . . . . . 9
10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12.1. CoAP Option Number . . . . . . . . . . . . . . . . . . . 10
12.2. URI Scheme Registration . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. SMS encoding . . . . . . . . . . . . . . . . . . . . 12
A.1. ASCII-optimized SMS encoding . . . . . . . . . . . . . . 12
Appendix B. Changelog . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
Kuladinithi, et al. Expires August 24, 2017 [Page 2]
Internet-Draft CoAP over SMS February 2017
1. Introduction
This specification details the usage of the Constrained Application
Protocol on the Short Message Service (SMS) 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 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.
1.2. Terminology
This document uses the following terminology:
CoAP Server and Client
The terms CoAP Server and CoAP Client are used synonymously to
Server and Client as specified in the terminology section of
[RFC7252].
Mobile Station (MS)
A Mobile Station includes all required user equipment and software
that is needed for communication with a mobile network. As
defined in [etsi_ts101_748].
Kuladinithi, et al. Expires August 24, 2017 [Page 3]
Internet-Draft CoAP over SMS February 2017
1.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].
2. Scenarios
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.
2.1. MO-MT Scenarios
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).
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)
2.2. MT Scenarios
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).
Kuladinithi, et al. Expires August 24, 2017 [Page 4]
Internet-Draft CoAP over SMS February 2017
CIMD CoAP-REQ
+------+ SMPP +-------+ (SMS) +------+
| A | --------> | SMS-C | ---------> | B |
| (IP) | <-------- | | <--------- |(cell)|
+------+ +-------+ CoAP-RES +------+
(SMS)
Figure 2: IP and Cellular Communication
There are service providers that offer SMS delivery and notification
using an HTTP/REST interface (depicted in Figure 3).
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)
2.3. MO Scenarios
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).
CoAP-REQ CIMD
+------+ (SMS) +-------+ SMPP +------+
| A | --------> | SMS-C | ---------> | B |
|(cell)| <-------- | | <--------- | (IP) |
+------+ CoAP-RES +-------+ +------+
(SMS)
Figure 4: Cellular and IP Communication
There are service providers offering SMS delivery and notification
using an HTTP/REST interface (depicted in Figure 5).
Kuladinithi, et al. Expires August 24, 2017 [Page 5]
Internet-Draft CoAP over SMS February 2017
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)
3. Message Exchanges
3.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 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
Kuladinithi, et al. Expires August 24, 2017 [Page 6]
Internet-Draft CoAP over SMS February 2017
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.
4. Encoding Schemes of CoAP for SMS transport
Short messages can be encoded by using various alphabets: GSM 7 bit
default alphabet ([ts23_038]), 8 bit data alphabet, and 16 bit UCS2
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. UCS2 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 preferred encoding scheme for CoAP messages
over SMS is therefore 7 bit, e.g. Base64 ([RFC4648]) or SMS encoding
in Appendix A.1.
More considerations about SMS encoding can be found in Appendix A.
5. Message Size Implementation Considerations
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:
Concatenated short messages
Most MSs are able to send concatenation short messages in order to
transmit longer messages. The total length of a concatenated
short message can consist of up to 255 single messages and result
Kuladinithi, et al. Expires August 24, 2017 [Page 7]
Internet-Draft CoAP over SMS February 2017
in total length of 39015 7 bit characters or 34170 bytes.
Resulting from this, the maximum length of each individual message
reduces to 153 (160 - 7) characters (133 bytes).
CoAP block-wise transfer
According to [RFC7959], the Block Size (SZX) of block-wise
transfer in CoAP is represented as a three-bit unsigned integer.
Thus, the possible block sizes are to the power of two. (Block
size = 2**(SZX + 4)). Due to the limitations of 160 characters
(140 bytes) for one short message, the maximum value of SZX is 3
(Block size = 128 byte).
However, it is RECOMMENDED that SMS is not used to transfer very
large resource data using block-wise transfer.
6. 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 short message contains a
CoAP message, the TP-DATA-Coding-Scheme SHOULD be included.
7. Options
7.1. New Options for mixed IP operation.
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- | string | 1-270 | (none) |
| | | | | | Uri-Host | | B | |
| TBD | | | | | Response-To- | uint | 0-2 B | 5683 |
| | | | | | Uri-Port | | | |
+-----+---+---+---+---+-----------------+--------+--------+---------+
Table 1: New CoAP Option Numbers
Kuladinithi, et al. Expires August 24, 2017 [Page 8]
Internet-Draft CoAP over SMS February 2017
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.
8. URI Scheme
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 proposed 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.
9. Transmission Parameters
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.
10. Multicast
Multicast is not possible with SMS transports.
11. Security Considerations
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
Kuladinithi, et al. Expires August 24, 2017 [Page 9]
Internet-Draft CoAP over SMS February 2017
allowed to send requests. The requests from others will be ignored
or rejected.
12. IANA Considerations
12.1. CoAP Option Number
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 |
+--------+----------------------+----------------------------+
12.2. URI Scheme Registration
According to [I-D.silverajan-core-coap-alternative-transports] this
document requests the registration of the Uniform Resource Identifier
(URI) scheme "coap+sms". The registration request complies with
[RFC7595].
13. References
13.1. Normative References
[etsi_ts101_748]
ETSI, "Technical Report: Digital cellular
telecommunications system; Abbreviations and acronyms (GSM
01.04 version 8.0.0 release 1999)", 2000.
[iso_ucs2]
ISO, "ISO/IEC10646: "Universal Multiple-Octet Coded
Character Set (UCS)"; UCS2, 16 bit coding.", 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
Kuladinithi, et al. Expires August 24, 2017 [Page 10]
Internet-Draft CoAP over SMS February 2017
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
and Registration Procedures for URI Schemes", BCP 35,
RFC 7595, DOI 10.17487/RFC7595, June 2015,
<http://www.rfc-editor.org/info/rfc7595>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<http://www.rfc-editor.org/info/rfc7959>.
[ts23_038]
ETSI 3GPP, "Technical Specification: Alphabets and
language-specific information (3GPP TS 23.038 version
11.0.0 Release 11)", 2012.
13.2. Informative References
[cimd] Nokia, "CIMD Interface Specification (SMSCDOC8000.00,
Nokia SMS Center 8.0)", 2005.
[I-D.silverajan-core-coap-alternative-transports]
Silverajan, B. and T. Savolainen, "CoAP Communication with
Alternative Transports", draft-silverajan-core-coap-
alternative-transports-09 (work in progress), December
2015.
[oma_lightweightm2m_ts]
OMA, "Lightweight Machine to Machine Technical
Specification", 2013.
[RFC1924] Elz, R., "A Compact Representation of IPv6 Addresses",
RFC 1924, DOI 10.17487/RFC1924, April 1996,
<http://www.rfc-editor.org/info/rfc1924>.
[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, March 2011.
Kuladinithi, et al. Expires August 24, 2017 [Page 11]
Internet-Draft CoAP over SMS February 2017
[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.
Appendix A. SMS encoding
For use in SMS applications, CoAP messages can be transferred using
SMS binary mode. However, there is operational experience showing
that some environments cannot successfully send a binary mode SMS.
For transferring SMS in character mode (7-bit characters),
base64-encoding [RFC4648] is an obvious choice. 3 bytes of message
(24 bits) turn into 4 characters, which consume 28 bits. The overall
overhead is approximately 17 %; the maximum message size is 120 bytes
(160 SMS characters).
If a more compact encoding is desired, base85 encoding could be
employed (however, probably not the version defined in [RFC1924] --
instead, the version used in tools such as btoa and PDF should be
chosen). However, this requires division operations. Also, the
base85 character set includes several characters that cannot be
transferred in a single 7-bit unit in SMS and/or are known to cause
operational problems. A modified base85 character set can be defined
to solve the latter problem. 4 bytes of message (32 bits) turn into
5 characters, which consume 35 bits. The overall overhead is
approximately 9.3 %; the resulting maximum message size is 128 bytes
(160 SMS characters).
Base64 and base85 do not make use of the fact that much CoAP data
will be ASCII-based. Therefore, we define the following ASCII-
optimized SMS encoding.
A.1. ASCII-optimized SMS encoding
Not all 128 theoretically possible SMS characters are operationally
free of problems. We therefore define:
Kuladinithi, et al. Expires August 24, 2017 [Page 12]
Internet-Draft CoAP over SMS February 2017
Shunned code characters: @ sign, as it maps to 0x00
LF and CR signs (0x0A, 0x0D)
uppercase C cedilla (0x09), as it is often mistranslated in
gateways
ESC (0x1B), as it is used in certain character combinations only
Some ASCII characters cannot be transferred in the base SMS character
set, as their code positions are taken by non-ASCII characters.
These are simply encoded with their ASCII code positions, e.g., an
underscore becomes a section mark (even though underscore has a
different code position in the SMS character set).
Equivalently translated input bytes: $, @, [, \, ], ^, _, `, {, |,
}, ~, DEL
In other words, bytes 0x20 to 0x7F are encoded into the same code
positions in the 7-bit character set.
Out of the remaining code characters, the following SMS characters
are available for encoding:
Non-equivalently translated (NET) code characters: 0x01 to 0x08, (8
characters)
0x0B, 0x0C, (2 characters)
0x0E to 0x1A, (13 characters)
0x1C to 0x1F, (4 characters)
Of the 27 NET code characters, 18 are taken as prefix characters (see
below), and 8 are defined as directly translated characters:
Directly translated bytes: Equivalently translated input bytes are
represented as themselves
0x00 to 0x07 are represented as 0x01 to 0x08
This leaves 0x08 to 0x1F and 0x80 to 0xFF. Of these, the bytes 0x80
to 0x87 and 0xA0 to 0xFF are represented as the bytes 0x00 to 0x07
(represented by characters 0x01 to 0x08) and 0x20 to 0x7F, with a
prefix of 1 (see below). The characters 0x08 to 0x1F are represented
as the characters 0x28 to 0x3F with a prefix of 2 (see below). The
characters 0x88 to 0x9F are represented as the characters 0x48 to
0x5F with a prefix of 2 (see below). (Characters 0x01 to 0x08, 0x20
Kuladinithi, et al. Expires August 24, 2017 [Page 13]
Internet-Draft CoAP over SMS February 2017
to 0x27, 0x40 to 0x47, and 0x60 to 0x7f with a prefix of 2 are
reserved for future extensions, which could be used for some
backreferencing or run-length compression.)
Bytes that do not need a prefix (directly translated bytes) are sent
as is. Any byte that does need a prefix (i.e., 1 or 2) is preceded
by a prefix character, which provides a prefix for this and the
following two bytes as follows:
+------+-----+---+------+-----+
| char | pfx | . | char | pfx |
+------+-----+---+------+-----+
| 0x0B | 100 | . | 0x15 | 200 |
| 0x0C | 101 | . | 0x16 | 201 |
| 0x0E | 102 | . | 0x17 | 202 |
| 0x0F | 110 | . | 0x18 | 210 |
| 0x10 | 111 | . | 0x19 | 211 |
| 0x11 | 112 | . | 0x1A | 212 |
| 0x12 | 120 | . | 0x1C | 220 |
| 0x13 | 121 | . | 0x1D | 221 |
| 0x14 | 122 | . | 0x1E | 222 |
+------+-----+---+------+-----+
Table 2: SMS prefix character assignment
(This leaves one non-shunned character, 0x1F, for future extension.)
The coding overhead of this encoding for random bytes is similar to
Base85, without the need for a division/multiplication. For bytes
that are mostly ASCII characters, the overhead can easily become
negative. (Conversely, for bytes that for some reason are more
likely to be non-ASCII than in a random sequence of bytes, the
overhead becomes greater.)
So, for instance, for the CoAP message in Figure 7:
Kuladinithi, et al. Expires August 24, 2017 [Page 14]
Internet-Draft CoAP over SMS February 2017
ver tt code mid
1 ack 2.05 17033
content_type 40
token sometok
3c 2f 3e 3b 74 69 74 6c 65 3d 22 47 65 6e 65 72 |</>;title="Gener|
61 6c 20 49 6e 66 6f 22 3b 63 74 3d 30 2c 3c 2f |al Info";ct=0,</|
74 69 6d 65 3e 3b 69 66 3d 22 63 6c 6f 63 6b 22 |time>;if="clock"|
3b 72 74 3d 22 54 69 63 6b 73 22 3b 74 69 74 6c |;rt="Ticks";titl|
65 3d 22 49 6e 74 65 72 6e 61 6c 20 43 6c 6f 63 |e="Internal Cloc|
6b 22 3b 63 74 3d 30 2c 3c 2f 61 73 79 6e 63 3e |k";ct=0,</async>|
3b 63 74 3d 30 |;ct=0 |
Figure 7: CoAP response message as captured and decoded
The 116 byte unencoded message is shown as ASCII characters in
Figure 8 (\xDD stands for the byte with the hex digits DD):
bEB\x89\x11(\xA7sometok</>;title="General Info";ct=0,</time>
;if="clock";rt="Ticks";title="Internal Clock";ct=0,</async>;ct=0
Figure 8: CoAP response message shown as unencoded characters
The only non-ASCII characters in this example are in the beginning of
the message. According to the translation instructions above, the
four bytes:
89 11 ( A7
need the prefixes:
2 2 0 1
As each prefix character always covers three unencoded bytes, we need
the prefix characters for 220 and 100, which are \x1C and \x0B,
respectively (Table 2).
The equivalent SMS encoding is shown as equivalent-coded SMS
characters in Figure 9 (7 bits per character, \x1C is the 220 prefix
and \x0B is the 100 prefix, the rest is shown in equivalent
encoding), adding two characters of prefix overhead, for a total
length of 118 7-bit characters or 104 (103.25 plus padding) bytes:
bEB\x1CI1(\x0B'sometok</>;title="General Info";ct=0,</time>
;if="clock";rt="Ticks";title="Internal Clock";ct=0,</async>;ct=0
Figure 9: CoAP response message shown as SMS-encoded characters
Kuladinithi, et al. Expires August 24, 2017 [Page 15]
Internet-Draft CoAP over SMS February 2017
Appendix B. Changelog
RFC editor: please remove this appendix.
Changed from draft-05 to draft-06:
o Update references and addresses
o Integrate relevant text from coap-misc as an appendix.
o Section 2 & 3 are merged to section 1
Changed from draft-04 to draft-05:
o Removed reference to USSD.
o Updated reference to RFC7252 and 3GPP specs.
o Updated Options.
o Adapted URI scheme.
Changed from draft-03 to draft-04:
o Removed USSD and GPRS related parts.
o Removed section 5: Examples
o Removed section 14: Proxying Considerations
o Added more block size considerations.
o Added more concatenated SMS considerations.
o Rewrote encoding scheme section; 7 bit encoding only.
Changed from draft-02 to draft-03:
o Added reference to OMA LightweightM2M Technical Specification in
"Motivation" section.
o Chose CoAP option numbers and updated the option number table to
meet draft-ietf-core-coap-13.
Changed from draft-01 to draft-02:
o Added security considerations: Transport and Object Security.
Section 11
Kuladinithi, et al. Expires August 24, 2017 [Page 16]
Internet-Draft CoAP over SMS February 2017
o Reply-To-* changed to Response-To-*. Section 12
o Added URI scheme.
o Added possible CON/NON/ACK interactions.
o Added possible M2M proxy scenarios.
o Added reference to bormann-coap-misc for other SMS encoding.
Section 4
o Updated requirements on Uri-Host and Uri-Port for coap+tel://.
o Chose CoAP option numbers and updated the option number table to
meet draft-ietf-core-coap-10. />
o Added an IANA registration for the URI scheme. Section 12.2
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 Goetting, Nils Schulte and Klaus Hartke for the discussions on
the topic and the reviews of this document.
Contributors
Appendix A has been contributed by Carsten Bormann.
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
EMail: cabo@tzi.org
Authors' Addresses
Kuladinithi, et al. Expires August 24, 2017 [Page 17]
Internet-Draft CoAP over SMS February 2017
Koojana Kuladinithi (editor)
ComNets, Hamburg University of Technology
Am Schwarzenberg-Campus 3
Hamburg 21073
Germany
Phone: +49 40 428 783533
Email: koojana.kuladinithi@tuhh.de
Markus Becker
Tridonic GmbH & Co KG
Faerbergasse 15
Dornbirn 6851
Austria
Phone: +43 5572 395 45637
Email: markus.becker@tridonic.com
Kepeng LI
Alibaba Group
Wenyixi Road, Yuhang District
Hangzhou, Zhejiang 311121
China
Email: kepeng.lkp@alibaba-inc.com
Thomas Poetsch
New York University Abu Dhabi
P.O. Box 129188
Abu Dhabi 129188
United Arab Emirates
Phone: +971 2 628 5069
Email: thomas.poetsch@nyu.edu
Kuladinithi, et al. Expires August 24, 2017 [Page 18]
