One document matched: draft-becker-core-coap-sms-gprs-00.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 RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.ietf-core-block SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-block.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="yes" ?>
<!-- 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="info" docName="draft-becker-core-coap-sms-gprs-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="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 SMS/GPRS">Transport of CoAP over SMS and GPRS</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Markus Becker" initials="M.B." 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 fullname="Koojana Kuladinithi" initials="K.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.P." 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="2011" />
<!-- 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 Working Group </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, GPRS</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>The Short Message Service (SMS) of mobile cellular networks
is frequently used in Machine-To-Machine (M2M) communications,
such as for telematic devices. The service offers small packet
sizes and high delays just as other typical low-power and lossy
networks (LLNs), i.e. 6LoWPANs. The design of the Constrained
Application Protocol (CoAP), that took the limitations of LLNs
into account, is thus also applicable to telematic M2M
devices. The adaption of CoAP to the SMS transport mechanism is
described in this document.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This specification details the usage of the Constrained
Application Protocol on the Short Message Service of mobile
cellular networks.</t>
<section title="Scenarios">
<t>
<xref target="cell2cell_sms" /> to <xref
target="ip2cell_sms_prov" /> 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
<xref target="cell2cell_sms" />).
<figure align="center" anchor="cell2cell_sms" title="Cellular and Cellular Communication (only SMS-based)">
<artwork align="center"><![CDATA[
CoAP-REQ
+------+ (SMS) +------+
| A | -------> | B |
|(cell)| <------- |(cell)|
+------+ CoAP-RES +------+
(SMS)
]]></artwork>
</figure>
Two mobile cellular terminals communicate by exchanging the CoAP
Request in an SMS PDU and the CoAP Responce using GPRS
transport. (depicted in <xref target="cell2cell_sms_gprs" />).
<figure align="center" anchor="cell2cell_sms_gprs" title="Cellular and Cellular Communication (SMS/GPRS-based)">
<artwork align="center"><![CDATA[
CoAP-REQ
+------+ (SMS) +------+
| A | -------> | B |
|(cell)| <------- |(cell)|
+------+ CoAP-RES +------+
(GPRS)
]]></artwork>
</figure>
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. Computer Interface to Message
Distribution (CIMD <xref target="cimd" />), Universal Computer
Protocol/External Machine Interface (UCP/EMI <xref target="ucp"
/>), Short Message Peer-to-Peer (SMPP <xref target="smpp" />) ) to
submit an SMS for delivery, which contains the CoAP Request
(depicted in <xref target="ip2cell_sms" />).
<figure align="center" anchor="ip2cell_sms" title="IP and Cellular Communication (only SMS-based)">
<artwork align="center"><![CDATA[
CIMD
UCP/EMI CoAP-REQ
+------+ SMPP +-------+ (SMS) +------+
| A | --------> | SMS-C | -------> | B |
| (IP) | <-------- | | <------- |(cell)|
+------+ +-------+ CoAP-RES +------+
(SMS)
]]></artwork>
</figure>
Again, the return path for the CoAP response might be GPRS (depicted in
<xref target="ip2cell_sms_gprs" />).
<figure align="center" anchor="ip2cell_sms_gprs" title="IP and Cellular Communication (SMS/GPRS-based)">
<artwork align="center"><![CDATA[
CIMD
UCP/EMI CoAP-REQ
+------+ SMPP +-------+ (SMS) +------+
| A | --------> | SMS-C | -------> | B |
| (IP) | | | |(cell)|
+------+ +-------+ +------+
^ |
| +-------+ |
| | GGSN | |
+-------------- | | <-----------+
+-------+ CoAP-RES
(GPRS)
]]></artwork>
</figure>
There are service providers offering 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 (only SMS-based, using an SMS service provider)">
<artwork align="center"><![CDATA[
CIMD
HTTP-REQ UCP/EMI CoAP-REQ
+------+ (CoAP-DATA) +-----------+ SMPP +-----+ (SMS) +------+
| A | ----------> |SMS Service| ------> |SMS-C| -------> | B |
| (IP) | <---------- |Provider | <------ | | <------- |(cell)|
+------+ HTTP-RES +-----------+ +-----+ CoAP-RES +------+
(CoAP-DATA) (SMS)
]]></artwork>
</figure>
At the moment, this document assumes the scenarios shown in
<xref target="cell2cell_sms" />, <xref target="ip2cell_sms" />
and <xref target="ip2cell_sms_prov" />), i.e.\ only SMS
transport.
</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>
<section title="Encoding of CoAP for SMS transport">
<t>The content of SMS can be coded in 7, 8 or 16 bit characters <xref
target="3gpp_ts23.038" />. The advantages and disadvantages
are:
<list style="letters">
<t>7 bit encoding: Sending 7 bit encoded SMS possible with
almost all devices. CoAP binary data needs to be re-encoded,
possibly with <xref target="RFC4648">Base64 RFC
4648</xref>.</t>
<t>8 bit encoding: CoAP binary data does not need to be
re-encoded. Not all telematic devices support 8 bit SMS
encoding.</t>
<t>16 bit encoding: CoAP binary data needs to be
re-encoded. Not all telematic devices support 16 bit SMS
encoding.</t>
</list>
The currently safest solution is to use 7 bit encoded SMS
including Base64 encoded CoAP payload.
</t>
</section>
<section title="Message Size Implementation Considerations">
<t>Using 7 bit encoding 160 characters are allowed in 1 SMS, while
using 8 bit encoding 140 characters are allowed. <xref
target="3gpp_ts23.038" /></t>
<t>Possible options for larger CoAP messages are:
<list style="letters">
<t>Multiple SMS concatenation</t>
<t>CoAP Block <xref target="I-D.ietf-core-block" /></t>
</list>
</t>
</section>
<section title="Options">
<t>Uri-Host and Uri-Port options MUST NOT be included in the
CoAP header. End-points receiving CoAP messages over SMS with
such options MUST behave as specified in <xref
target="I-D.ietf-core-coap" />.</t>
<t>Open question: Is the introduction of a new CoAP option
Reply-To-Uri-Host necessary, if the server should use the GPRS
transport for the Response? This relates to <xref
target="cell2cell_sms_gprs" /> and <xref
target="ip2cell_sms_gprs" />.
</t>
<texttable anchor="table_coap_option" title="New CoAP Option Numbers">
<ttcol align="center">Number</ttcol>
<ttcol align="center">C/E</ttcol>
<ttcol align="center">Name</ttcol>
<ttcol align="center">Format</ttcol>
<ttcol align="center">Length</ttcol>
<ttcol align="center">Default</ttcol>
<c>17</c>
<c>Critical</c>
<c>Reply-To-Uri-Host</c>
<c>string</c>
<c>1-270 B</c>
<c>(none)</c>
<c>19</c>
<c>Critical</c>
<c>Reply-To-Uri-Port</c>
<c>uint</c>
<c>0-2 B</c>
<c>(none)</c>
</texttable>
</section>
<section title="Protocol Constants">
<t>The RESPONSE_TIMEOUT variable SHOULD be configured for a
higher duration than specified in <xref
target="I-D.ietf-core-coap" />, i.e. 10 s.</t>
</section>
<section title="Multicast">
<t>Multicast MUST not be used with the SMS transport.</t>
</section>
<section title="Proxying Considerations">
<t>TBD (Proxying into an IPv6/v4 network (e.g. a 6LoWPAN
network) possible?)</t>
</section>
<section title="SMS URI scheme for link-format">
<t>Open question: Make use of RFC5724 SMS URI scheme?</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document is based on research for the research project
'The Intelligent Container' which is supported by the Federal
Ministry of Education and Research, Germany, under reference
number 01IA10001.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t> This presents no security considerations beyond those in
section 10 of the base CoAP specification <xref
target="I-D.ietf-core-coap" />.</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">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC4648;
&I-D.ietf-core-coap;
&I-D.ietf-core-block;
<reference anchor="3gpp_ts23.038">
<front>
<title>Technical Specification: Alphabets and
language-specific information (3GPP TS 23.038 version 10.0.0
Release 10)</title>
<author>
<organization>ETSI 3GPP</organization>
</author>
<date year="2011" />
</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>
</references>
<!-- <section anchor="app-additional" title="Additional Stuff"> -->
<!-- <t>This becomes an Appendix.</t> -->
<!-- </section> -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:33:42 |