One document matched: draft-becker-core-coap-sms-gprs-05.xml
<?xml version="1.0" encoding="utf-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3966 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY I-D.ietf-core-block SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-block.xml">
<!ENTITY I-D.bormann-coap-misc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-coap-misc.xml">
<!ENTITY I-D.silverajan-core-coap-alternative-transports SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.silverajan-core-coap-alternative-transports.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-becker-core-coap-sms-gprs-05" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and ob soletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="CoAP over SMS">Transport of CoAP over SMS</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Markus Becker" initials="M." role="editor"
surname="Becker">
<organization>ComNets, TZI, University Bremen</organization>
<address>
<postal>
<street>Bibliothekstrasse 1</street>
<code>28359</code>
<city>Bremen</city>
<country>Germany</country>
</postal>
<phone>+49 421 218 62379</phone>
<email>mab@comnets.uni-bremen.de</email>
</address>
</author>
<author initials="K." surname="Li" fullname="Kepeng Li">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P. R. China</country>
</postal>
<phone>+86-755-28974289</phone>
<email>likepeng@huawei.com</email>
</address>
</author>
<author fullname="Koojana Kuladinithi" initials="K." surname="Kuladinithi">
<organization>ComNets, TZI, University Bremen</organization>
<address>
<postal>
<street>Bibliothekstrasse 1</street>
<code>28359</code>
<city>Bremen</city>
<country>Germany</country>
</postal>
<phone>+49 421 218 62382</phone>
<email>koo@comnets.uni-bremen.de</email>
</address>
</author>
<author fullname="Thomas Pötsch" initials="T." surname="Pötsch">
<organization>ComNets, TZI, University Bremen</organization>
<address>
<postal>
<street>Bibliothekstrasse 1</street>
<code>28359</code>
<city>Bremen</city>
<country>Germany</country>
</postal>
<phone>+49 421 218 62379</phone>
<email>thp@comnets.uni-bremen.de</email>
</address>
</author>
<date year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Application</area>
<workgroup>CoRE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>CoAP, SMS, M2M</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<!--
DONE: Clearified in text:
CoAP IP Client, Mobile Terminated CoAP Server:
* End-To-End CoAP (over cellular IP transport, MT always on)
* End-To-End CoAP (over cellular IP transport, network initiated PDP context)
* CoAP payload in non-IP transport (SMS/USSD)
* both directions non-IP
* only request non-IP, response in IP
-> Why: Power of mobile. Coverage.
Mobile Originated CoAP Client, (CoAP) IP Server:
* End-To-End CoAP (over cellular IP transport)
* CoAP payload in non-IP transport (SMS/USSD)
* CoAP-HTTP Proxy at mobile network border or in server network
* both directions non-IP
-> Why: Coverage.
Mobile Originated and Terminated CoAP:
* End-To-End CoAP (over cellular IP transport, MT always on)
* End-To-End CoAP (over cellular IP transport, network initiated PDP context)
* CoAP payload in non-IP transport (SMS/USSD)
* both directions non-IP
* only request non-IP, response in IP
-> Why: Power of mobile. Simplicity.
CoAP Proxy on Mobile:
* CoAP-CoAP Proxy into 6LoWPAN
-->
<middle>
<section title="Introduction">
<t>
This specification details the usage of the Constrained
Application Protocol on the Short Message Service (SMS) of
mobile cellular networks.
</t>
<section title="Motivation">
<t>
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.
</t>
<t>
In 3GPP, SMS is identified as the transport protocol for
small data transmissions (See <xref target="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 <xref
target="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).
</t>
<t>
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.
</t>
<t>
In Open Mobile Alliance (OMA) LightweightM2M technical
specification <xref target="oma_lightweightm2m_ts" />, SMS is
identified as an alternative transport for CoAP messages.
</t>
<!--<t>
Where short messages are normally stored in the SMS Center
(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".
</t>-->
</section>
</section>
<section title="Terminology">
<t>
This document uses the following terminology:
<list style="hanging">
<t hangText="CoAP Server and Client"><vspace /> The terms CoAP
Server and CoAP Client are used synonymously to Server and
Client as specified in the terminology section of <xref
target="RFC7252" />.
</t>
<t hangText="Mobile Station (MS)"><vspace /> A Mobile Station
includes all required user equipment and software that is needed
for communication with a mobile network. As defined in <xref
target="etsi_ts101_748" />.
</t>
</list>
</t>
</section>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
<section title="Scenarios">
<t>
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.
</t>
<!--
<t>
<xref target="cell2cell_sms" /> to <xref
target="ip2cell_sms_prov" /> show various applicable usage
scenarios of CoAP in M2M communications.
</t>
-->
<section title="MO-MT Scenarios">
<t>
Two mobile cellular terminals communicate by exchanging a CoAP
Request and Response embedded into short message protocol data
units (PDUs) (depicted in <xref target="cell2cell_sms"
/>). Both terminals are connected via a Short Message Service
Centre (SMS-C).
<figure align="center" anchor="cell2cell_sms" title="Cellular and Cellular Communication (only SMS-based)">
<artwork align="center"><![CDATA[
CoAP-REQ CoAP-REQ
+------+ (SMS) +-------+ (SMS) +------+
| A | --------> | SMS-C | -------> | B |
|(cell)| <-------- | | <------- |(cell)|
+------+ CoAP-RES +-------+ CoAP-RES +------+
(SMS) (SMS)
]]></artwork>
</figure>
<!-- The support for GPRS for the CoAP responses might be useful, so
as to use SMS only for the request and as a wake-up signal for
the device hosting the CoAP server. That device could then
initiate a packet data protocol (PDP) context with the cellular
network in order to bring up Internet connectivity. After having
setup Internet connectivity, further message exchange can fully
rely on IP. Network initiated PDP contexts could partly obsolete
this mechanism.
-->
</t>
</section>
<section title="MT Scenarios">
<t>
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 <xref target="smpp" />), Computer
Interface to Message Distribution (CIMD <xref target="cimd"
/>), Universal Computer Protocol/External Machine Interface
(UCP/EMI <xref target="ucp" />)) to submit a short message
for delivery, which contains the CoAP Request (depicted in
<xref target="ip2cell_sms" />).
<figure align="center" anchor="ip2cell_sms" title="IP and Cellular Communication">
<artwork align="center"><![CDATA[
CIMD CoAP-REQ
+------+ SMPP +-------+ (SMS) +------+
| A | --------> | SMS-C | ---------> | B |
| (IP) | <-------- | | <--------- |(cell)|
+------+ +-------+ CoAP-RES +------+
(SMS)
]]></artwork>
</figure>
There are service providers that offer SMS delivery and
notification using an HTTP/REST interface (depicted in <xref
target="ip2cell_sms_prov" />).
<figure align="center" anchor="ip2cell_sms_prov" title="IP and Cellular Communication (using an SMS Service Provider)">
<artwork align="center"><![CDATA[
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)
]]></artwork>
</figure>
</t>
</section>
<section title="MO Scenarios">
<t>
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 <xref target="smpp" />), Computer Interface
to Message Distribution (CIMD <xref target="cimd" />),
Universal Computer Protocol/External Machine Interface
(UCP/EMI <xref target="ucp" />)) as depicted in <xref
target="cell2ip_sms" />). This scenario can be a fall-back for
mobile-originating communication, when IP connectivity cannot
be setup (e.g. due to missing coverage).
<figure align="center" anchor="cell2ip_sms" title="Cellular and IP Communication">
<artwork align="center"><![CDATA[
CoAP-REQ CIMD
+------+ (SMS) +-------+ SMPP +------+
| A | --------> | SMS-C | ---------> | B |
|(cell)| <-------- | | <--------- | (IP) |
+------+ CoAP-RES +-------+ +------+
(SMS)
]]></artwork>
</figure>
There are service providers offering SMS delivery and
notification using an HTTP/REST interface (depicted in <xref
target="cell2ip_sms_prov" />).
<figure align="center" anchor="cell2ip_sms_prov" title="IP and Cellular Communication (using an SMS Service Provider)">
<artwork align="center"><![CDATA[
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)
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="Message Exchanges">
<section title="Message Exchange for SMS in a Cellular-To-Cellular Mobile-Originated and Mobile-Terminated Scenario">
<t>
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:
</t>
<figure align="center" anchor="msc_sms" title="CoAP Messages over SMS">
<artwork> <![CDATA[
MS/CoAP CLIENT Service Center MS/CoAP SERVER
| | |
| ---SMS-SUBMIT---> | |
| <-SMS-SUBMIT-REPORT-- | |
| | |
| | --SMS-DELIVER---> |
| | <-SMS-DELIVER-REPORT-- |
| | |
| <-SMS-STATUS-REPORT-- | |
| | |
]]>
</artwork>
</figure>
<t>
Note that the message exchange is just for one request
message from CoAP Client and CoAP Server. It includes the
following steps:
</t>
<t>
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 <xref
target="ts23_040" />).
</t>
<t>
Step 2: The Service Center returns a SMS-SUBMIT-REPORT
message to the CoAP Client.
</t>
<t>
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 <xref target="ts23_040" />).
</t>
<t>
Step 4: The CoAP Server returns an SMS-DELIVER-REPORT message
to the Service Center.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Encoding Schemes of CoAP for SMS transport" anchor="sms_encoding">
<t>
Short messages can be encoded by using various alphabets: GSM
7 bit default alphabet (<xref target="ts23_038" />), 8
bit data alphabet, and 16 bit USC2 data alphabet (<xref
target="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.
</t>
<t>
According to <xref target="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 (<xref
target="RFC4648" />) or SMS encoding in <xref
target="I-D.bormann-coap-misc" />.
</t>
<t>
More considerations about SMS encoding can be found in <xref
target="I-D.bormann-coap-misc" />.
</t>
<!--
<t>
In order to apply 7 bit encoding to CoAP messages, the
implementation can use one of the following encoding
schemes:
<list style="letters">
<t>
Base64: <xref target="RFC4648">Base64 RFC
4648</xref>.
</t>
<t>
</t>
</list>
</t>
-->
<!--
The currently safest solution is to use 7 bit encoded SMS
including Base64 encoded CoAP payload.
-->
</section>
<section title="Message Size Implementation Considerations">
<t>
By using 7 bit encoding, a maximum length of 160 characters is
allowed in one short message <xref target="ts23_038"
/>. Consequently, the maximum length for a CoAP message
results in 140 bytes. 160 characters = (140 bytes * 8)/7.
</t>
<t>
Possible options for larger CoAP messages are:
<list style="hanging">
<t hangText="Concatenated short messages"><vspace /> Most
MSs are able to send concatenation short messages in order
to tranmsit longer messages. The total length of a
concatenated short message can consist of up to 255 single
messages and result 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).
</t>
<t hangText="CoAP blockwise transfer"><vspace /> According
to <xref target="I-D.ietf-core-block" />, the Block Size
(SZX) of blockwise 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).
</t>
</list>
However, it is RECOMMENDED that SMS is not used to transfer very large
resource data using blockwise transfer.
</t>
</section>
<section title="Addressing">
<t>
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).
</t>
<t>
To allow the CoAP client to detect that the short message
contains a CoAP message, the TP-DATA-Coding-Scheme SHOULD be
included.
</t>
</section>
<section anchor="opt_uri" title="Options">
<!-- <t> Uri-Host: Contrary to the default value of the Uri-Host
Option being the IP literal as given in <xref
target="RFC7252" />, the default value when using
CoAP with the coap+tel:// scheme is the telephone-subscriber as
defined in RFC3966. If Uri-Host is not the default value, the
value is an IP literal as in <xref
target="RFC7252" />
</t>
<t>
Uri-Port: The default value of the Uri-Port is not useful in
combination with the coap+tel:// scheme. Therefore Uri-Port
MUST NOT be included, if the Uri-Host is the default value or
is not included in the message.
</t>
<t>
End-points receiving CoAP messages over SMS with such options
MUST behave as specified in <xref target="RFC7252"
/>.
</t>
-->
<section anchor="options" title="New Options for mixed IP operation.">
<!-- <t>
When CoAP should be used in mixed IP and non-IP mode the
server needs to be informed about the client's alternative
address that should be used for the CoAP Response. For this
reason the new options Response-To-Uri-Host and
Response-To-Uri-Port are proposed.
</t>
-->
<t>
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.
</t>
<texttable anchor="table_coap_option" title="New CoAP Option Numbers">
<ttcol align="center">No.</ttcol>
<ttcol align="center">C</ttcol>
<ttcol align="center">U</ttcol>
<ttcol align="center">N</ttcol>
<ttcol align="center">R</ttcol>
<ttcol align="center">Name</ttcol>
<ttcol align="center">Format</ttcol>
<ttcol align="center">Length</ttcol>
<ttcol align="center">Default</ttcol>
<c>TBD</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Response-To-Uri-Host</c>
<c>string</c>
<c>1-270 B</c>
<c>(none)</c>
<c>TBD</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Response-To-Uri-Port</c>
<c>uint</c>
<c>0-2 B</c>
<c>5683</c>
</texttable>
<t>
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.
</t>
<t>The options SHOULD NOT be used in the response.</t>
<t>The options MUST NOT occur more than once.</t>
</section>
</section>
<section anchor="urischeme" title="URI Scheme">
<t>
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.
</t>
<t>
As specified in <xref target="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.
</t>
<t>Example of such URI : </t>
<t>
o coap+sms://0015105550101/sensors/temperature
</t>
<t>In the URI, 0015105550101 is a telephone subscriber number. </t>
<!--
The URI scheme for CoAP over SMS is derived from the CoAP
scheme in <xref target="RFC7252" />.
As there is no host and port available for the SMS transport,
those parts are replaced with the "telephone-subscriber" from
<xref target="RFC3966" />.
-->
<!--
<section title="URI Scheme">
<t>
The syntax of the "coap+tel" URI scheme is specified below
in Augmented Backus-Naur Form (ABNF) <xref
target="RFC5234"/>.
The definitions of "path-abempty", "query", are adopted
from <xref target="RFC3986"/>. The definition of
"telephone-subscriber" is adopted from <xref
target="RFC3966"/>.
</t>
-->
<!--
<section title="Formal Definition">
<figure>
<artwork><![CDATA[
coap-sms-URI = "coap+tel:" "//" telephone-subscriber
path-abempty [ "?" query ]
telephone-subscriber = <defined in RFC3966">"
path-abempty = <defined in RFC3986">"
query = <defined in RFC3986">"
]]></artwork>
</figure>
</section>
-->
<!--
<section title="Example">
<figure>
<artwork type="example"><![CDATA[
coap+tel://+15105550101/.well-known/core
]]></artwork>
</figure>
</section>
</section>
-->
</section>
<section title="Transmission Parameters">
<t>
It is RECOMMENDED to configure the RESPONSE_TIMEOUT variable
for a higher duration than specified in <xref
target="RFC7252" /> for the applications described
here. The actual value SHOULD be chosen based on experience
with SMS <!--and GPRS-->.
</t>
</section>
<section title="Multicast">
<t>Multicast is not possible with SMS transports.
<!--
Multicast MUST NOT be used with the SMS and USSD transports.
-->
</t>
</section>
<!--
<section title="SMS URI scheme for link-format">
<t>OPEN QUESTION: Make use of RFC5724 SMS URI scheme?
Example: sms:+15105550101</t>
</section>
-->
<!-- Possibly a 'Contributors' section ... -->
<section anchor="Security" title="Security Considerations">
<t>
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.
</t>
<!-- <t>
As this option is used to redirect the response to another
address, it may be used by a malicious party to send it to an
address other than its own. For example, A can use his mobile
phone to send an SMS/CoAP GET, with B's IP address as
Response-To-Uri-Host. In this way, B will GET data that he
never requested.
</t>
<t>
To avoid this, server implementations need to verify if the
requesting client is a trusted client, and also verify if the
redirected address is a trusted address.
</t>
<t>
Security in the cellular network operator network at transport
layer by using dedicated Access Points Names (APNs) for the
GPRS M2M data.
Security for the access to the cellular network operator
network (for GPRS/IP as well as short message submission) can
be provided at transport layer as well, e.g. by Transport
Layer Security (TLS) or Virtual Private Networks (VPNs).
Security mechanisms defined in <xref target="ts23_888" />
are used to guarantee transport security.
The CoAP Payload can be secured using Object Security. If the
digital signature does not match pre-shared certificates or
decryption fails with a pre-shared key, the server SHOULD
ignore the message.
</t>
-->
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="IANA_options" title="CoAP Option Number">
<t>
The IANA is requested to add the following option number
entries to the CoAP Option Number Registry:
</t>
<figure>
<artwork>
+--------+----------------------+----------------------------+
| Number | Name | Reference |
+--------+----------------------+----------------------------+
| TBD | Response-To-Uri-Host | Section 2 of this document |
+--------+----------------------+----------------------------+
| TBD | Response-To-Uri-Port | Section 2 of this document |
+--------+----------------------+----------------------------+
</artwork>
</figure>
</section>
<section anchor="IANA_scheme" title="URI Scheme Registration">
<t>
According to <xref
target="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].
</t>
<!--
<t>
URI scheme name.
</t>
<t>
coap+tel
</t>
<t>
Status.
</t>
<t>
Permanent.
</t>
<t>
URI scheme syntax.
</t>
<t>
Defined in <xref target="urischeme" /> of [RFCXXXX].
</t>
<t>
URI scheme semantics.
</t>
<t>
TBD
</t>
<t>
Encoding considerations.
</t>
<t>
The scheme encoding conforms to the encoding rules
established for URIs in [RFC3986], i.e. internationalized
and reserved characters are expressed using UTF-8-based
percent-encoding.
</t>
<t>
Applications/protocols that use this URI scheme name.
</t>
<t>
The scheme is used by CoAP endpoints to access CoAP
resources over non-IP transports, i.e. cellular networks.
</t>
<t>
Interoperability considerations.
</t>
<t>
None.
</t>
<t>
Security considerations.
</t>
<t>
See <xref target="Security" /> of [RFCXXXX].
</t>
<t>
Contact.
</t>
<t>
IETF Chair <![CDATA[<]]>chair@ietf.org<![CDATA[>]]>
</t>
<t>
Author/Change controller.
</t>
<t>
IESG <![CDATA[<]]>iesg@ietf.org<![CDATA[>]]>
</t>
<t>
References.
</t>
<t>
[RFCXXXX]
</t>
-->
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
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.
</t>
<t>
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.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC2119;
&RFC3966;
&RFC3986;
&RFC4648;
&RFC5234;
<!-- &RFC5724;-->
&RFC7252;
&I-D.ietf-core-block;
&I-D.bormann-coap-misc;
&I-D.silverajan-core-coap-alternative-transports;
<reference anchor="iso_ucs2">
<front>
<title>ISO/IEC10646: "Universal Multiple-Octet Coded Character Set (UCS)”; UCS2, 16 bit coding.</title>
<author>
<organization>ISO</organization>
</author>
<date year="2000" />
</front>
</reference>
<reference anchor="etsi_ts101_748">
<front>
<title>Technical Report: Digital cellular telecommunications
system; Abbreviations and acronyms (GSM 01.04 version 8.0.0
release 1999)</title>
<author>
<organization>ETSI</organization>
</author>
<date year="2000" />
</front>
</reference>
<!-- coding scheme: SMS, USSD -->
<reference anchor="ts23_038">
<front>
<title>Technical Specification: Alphabets and
language-specific information (3GPP TS 23.038 version 11.0.0
Release 11)</title>
<author>
<organization>ETSI 3GPP</organization>
</author>
<date year="2012" />
</front>
</reference>
<!--
<reference anchor="ts22_090">
<front>
<title>Technical Specification: Digital cellular
telecommunications system (Phase 2+);Universal Mobile
Telecommunications System (UMTS);Unstructured Supplementary
Service Data (USSD);Stage 1 (3GPP TS 22.090 version 7.0.0
Release 7)</title>
<author>
<organization>ETSI 3GPP</organization>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="ts23_090">
<front>
<title>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)</title>
<author>
<organization>ETSI 3GPP</organization>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="ts24_090">
<front>
<title>Technical Specification: Digital cellular
telecommunications system (Phase 2+);Universal Mobile
Telecommunications System (UMTS);Unstructured Supplementary
Service Data (USSD);Stage 3 (3GPP TS 24.090 version 10.0.0
Release 10)</title>
<author>
<organization>ETSI 3GPP</organization>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="ts09_02_etsi_ts100974">
<front>
<title>Digital cellular telecommunications system (Phase
2+); Mobile Application Part (MAP) specification (3GPP TS
09.02 version 7.15.0 Release 1998)</title>
<author>
<organization>ETSI 3GPP</organization>
</author>
<date year="2004" />
</front>
</reference>
-->
</references>
<references title="Informative References">
<reference anchor="cimd">
<front>
<title>CIMD Interface Specification (SMSCDOC8000.00, Nokia
SMS Center 8.0)</title>
<author>
<organization>Nokia</organization>
</author>
<date year="2005" />
</front>
</reference>
<reference anchor="ucp">
<front>
<title>Short Message Service Centre (SMSC) External Machine Interface (EMI) Description Version 4.3d</title>
<author>
<organization>Vodafone</organization>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="smpp">
<front>
<title>Short Message Peer to Peer Protocol Specification
v3.4 Issue 1.2</title>
<author>
<organization>SMPP Developers Forum</organization>
</author>
<date year="1999" />
</front>
</reference>
<reference anchor="ts23_888">
<front>
<title>Technical Specification Group Services and System
Aspects; System Improvements for Machine-Type
Communications; (3GPP TR 23.888 version 1.6.0, Release
11)</title>
<author>
<organization>ETSI 3GPP</organization>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="ts23_040">
<front>
<title>Technical realization of the Short Message Service (SMS)</title>
<author>
<organization>3GPP</organization>
</author>
<date month="Mar" year="2011"/>
</front>
<seriesInfo name="3GPP-23.040" value="a00"/>
</reference>
<reference anchor="ts23_682">
<front>
<title>Technical Specification Group Services and System
Aspects; Architecture Enhancements to facilitate
communications with Packet Data Networks and Applications;
(Release 11)</title>
<author>
<organization>ETSI 3GPP</organization>
</author>
<date year="2012" />
</front>
</reference>
<reference anchor="oma_lightweightm2m_ts">
<front>
<title>Lightweight Machine to Machine
Technical Specification</title>
<author>
<organization>OMA</organization>
</author>
<date year="2013" />
</front>
</reference>
</references>
<section anchor="app-additional" title="Changelog">
<t>
Changed from draft-04 to draft-05:
<list style="symbols">
<t>Removed reference to USSD.</t>
<t>Updated reference to RFC7252 and 3GPP specs.</t>
<t>Updated Options.</t>
<t>Adapted URI scheme.</t>
</list>
</t>
<t>
Changed from draft-03 to draft-04:
<list style="symbols">
<t>Removed USSD and GPRS related parts.</t>
<t>Removed section 5: Examples</t>
<t>Removed section 14: Proxying Considerations</t>
<t>Added more block size considerations.</t>
<t>Added more concatenated SMS considerations.</t>
<t>Rewrote encoding scheme section; 7 bit encoding only.</t>
<!-- <t>TODO: Adapted URI sheme according to <xref
target="I-D.silverajan-core-coap-alternative-transports" /> </t>-->
</list>
</t>
<t>
Changed from draft-02 to draft-03:
<list style="symbols">
<t>Added reference to OMA LightweightM2M Technical Specification in "Motivation" section.</t>
<t>Chose CoAP option numbers and updated the option number table
to meet draft-ietf-core-coap-13.
</t>
</list>
</t>
<t>
Changed from draft-01 to draft-02:
<list style="symbols">
<t>Added security considerations: Transport and Object
Security. <xref target="Security" /></t>
<t>Reply-To-* changed to Response-To-*. <xref target="IANA" />
<!--and <xref target="options" />-->
</t>
<t>Added URI scheme.</t>
<t>Added possible CON/NON/ACK interactions.</t>
<t>Added possible M2M proxy scenarios.</t>
<t>Added reference to bormann-coap-misc for other SMS encoding. <xref target="sms_encoding" /></t>
<t>Updated requirements on Uri-Host and Uri-Port for coap+tel://.</t>
<t>Chose CoAP option numbers and updated the option number table
to meet draft-ietf-core-coap-10.
/></t>
<t>Added an IANA registration for the URI scheme. <xref
target="IANA_scheme" /></t>
</list>
</t>
</section>
</back> </rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:37:54 |