One document matched: draft-becker-core-coap-sms-gprs-02.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 RFC5724 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5724.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">
<!ENTITY I-D.bormann-coap-misc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-coap-misc.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="std" docName="draft-becker-core-coap-sms-gprs-02" 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 SMS/USSD/GPRS">Transport of CoAP over SMS, USSD and GPRS</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="2012" />
<!-- 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, GPRS, Response-To-URI</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) and Unstructured
Supplementary Service Data (USSD) of mobile cellular networks is
frequently used in Machine-To-Machine (M2M) communications, such
as for telematic devices. The service offers small packet sizes
and high delays just as other typical low-power and lossy
networks (LLNs), i.e. 6LoWPANs. The design of the Constrained
Application Protocol (CoAP), that took the limitations of LLNs
into account, is thus also applicable to telematic M2M
devices. The adaptation of CoAP to the SMS or USSD transport
mechanisms and the combination with IP transported over cellular
networks is described in this document.</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) or
Unstructured Supplementary Service Data (USSD) 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 and USSD will be supported, instead of
UDP/IP over General Packet Radio Service (GPRS), Hish Speed
Packet Access (HSPA) or Long Term Evolution (LTE) networks.
</t>
<t>
In Open Mobile Alliance (OMA), there is a new approved work
item named "the Lightweight M2M Protocol", which aims at
identifying requirements and defining protocols for M2M
applications in cellular networks.
</t>
<t>
In 3GPP, SMS is identified as the transport protocol for small
data transmissions (See <xref target="3gpp_ts23_888" /> for
Key Issue on Machine Type Communication (MTC) Device Trigger
and the proposed solutions in Sections 6.2, 6.42, 6.44, 6.48,
6.52, 6.60, and 6.61). In <xref target="3gpp_ts23_682" />
'Architecture Enhancements to facilitate communications with
Packet Data Networks and Applications' SMS is at the moment
the only Trigger Delivery (Trigger Delivery using T4).
USSD does seem to be in standardisation as a solution for MTC
Device Trigger.
</t>
<!-- Push USSD in 3GPP for MTC? -->
<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>
USSD is a very basic service in mobile networks which uses
fewer network components to provide a service similar to
SMS. This makes USSD very cheap for mobile network operators
and chipset manufactures as they do not have to provide
additional infrastructure. This is why USSD is from a
technical point of view supported by all handsets and other
mobile devices in all networks.
</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>
The terms CoAP Server and CoAP Client are used synonymously
to Server and Client as specified in the terminology section
of <xref target="I-D.ietf-core-coap" />.
</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. 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>
<section title="MO-MT 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 short message protocol data
units (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 CoAP-REQ
+------+ (SMS) +-------+ (SMS) +------+
| A | --------> | SMS-C | -------> | B |
|(cell)| <-------- | | <------- |(cell)|
+------+ CoAP-RES +-------+ CoAP-RES +------+
(SMS) (SMS)
]]></artwork>
</figure>
Two mobile cellular terminals communicate by exchanging the CoAP
Request in a short message PDU and the CoAP Response 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 CoAP-REQ
+------+ (SMS) +-------+ (SMS) +------+
| A | --------> | SMS-C | -------> | B |
|(cell)| | | |(cell)|
+------+ +-------+ +------+
^ |
| +-------+ |
| | GGSN | |
+-------------- | | <-----------+
CoAP-RES +-------+ CoAP-RES
(GPRS) (GPRS)
]]></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 (only SMS-based)">
<artwork align="center"><![CDATA[
CIMD 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 and GPRS-based)">
<artwork align="center"><![CDATA[
CIMD CoAP-REQ
+------+ SMPP +-------+ (SMS) +------+
| A | --------> | SMS-C | ---------> | B |
| (IP) | | | |(cell)|
+------+ +-------+ +------+
^ |
| +-------+ |
| | GGSN | |
+-------------- | | <-------------+
CoAP-RES +-------+ CoAP-RES
(IP) (GPRS)
]]></artwork>
</figure>
There are service providers offering SMS and/or USSD 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/USSD-based, using an SMS/USSD service provider)">
<artwork align="center"><![CDATA[
HTTP-REQ CIMD CoAP-REQ
+------+ (CoAP-DATA) +----------+ SMPP +-----+ (SMS/USSD) +------+
| | | SMS/USSD | SS7 |SMS-C| | |
| A | ----------> | Service | ------> | / | ---------> | B |
| (IP) | <---------- | Provider | <------ | HLR | <--------- |(cell)|
+------+ HTTP-RES +----------+ +-----+ CoAP-RES +------+
(CoAP-DATA) (SMS/USSD)
]]></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 (only SMS-based)">
<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 and/or USSD 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 (only SMS/USSD-based, using an SMS/USSD service provider)">
<artwork align="center"><![CDATA[
CoAP-REQ CIMD HTTP-REQ
+------+ (SMS/USSD) +-------+ SMPP +----------+ (CoAP-DATA) +----+
| | | SMS-C | SS7 | SMS/USSD | | |
| A | ---------> | / | -----> | Service | ----------> | B |
|(cell)| <--------- | HLR | <----- | Provider | <---------- |(IP)|
+------+ CoAP-RES +-------+ +----------+ HTTP-RES +----+
(SMS/USSD) (CoAP-DATA)
]]></artwork>
</figure>
If IP connectivity can be setup by the mobile cellular device,
the complete communication can be handled using UDP/IP by
employing regular CoAP <xref target="I-D.ietf-core-coap" />
(depicted in <xref target="cell2ip_gprs" />.
<figure align="center" anchor="cell2ip_gprs" title="Cellular and IP Communication (GPRS-based)">
<artwork align="center"><![CDATA[
+------+ CoAP-REQ +-------+ +------+
| A | --------> | GGSN | ---------> | B |
|(cell)| <-------- | | <--------- | (IP) |
+------+ CoAP-RES +-------+ +------+
]]></artwork>
</figure>
</t>
</section>
</section>
<section anchor="comm_examples" title="Examples">
<t>
Two mobile cellular terminals communicate by exchanging the
CoAP Request in an SMS PDU and the CoAP Response using GPRS
transport. (depicted in <xref
target="cell2cell_sms_simple" />).
</t>
<figure align="center" anchor="cell2cell_sms_simple">
<artwork>
<![CDATA[
CoAP-REQ
+-----------+ (SMS) +----------+
| Client | -----------> | Server |
| (cell) | <----------- | (cell) |
+-----------+ CoAP-RES +----------+
(GPRS)
]]>
</artwork>
</figure>
<t>
In the examples below, Client (Client Address A) sends GET
request to Server (Server Address A) through SMS, and uses
Response-To-URI-Host and Response-To-URI-Port to indicate the
IP address and port (Client Address B). Then the Server (Server
Address B) sends back the response to the Client through GPRS
to Client Address B. The tel: addresses in the examples are to
be interpreted as described in <xref target="RFC3966">RFC
3966</xref>.
</t>
<figure align="center" anchor="adresses">
<artwork>
<![CDATA[
Client Address A (CA): tel:+1-201-555-0123
Client Address B (CB): 10.1.1.1
Server Address A (SA): tel:+1-201-555-0124
Server Address B (SB): 10.1.1.2
]]>
</artwork>
</figure>
<!--
Klaus stated that the ACK needs to be from address SA. he
suggested to move to NON, since SMS is already
"reliable". (what about USSD?)
he stated to possibly even remove parts of the CoAP header
and introduce a shim SMS-adaptation layer.
I have put together possible combinations below:
-->
<!-- 2* NON's -->
<figure anchor="msc_nonA_nonB" title="NON A, NON B">
<artwork>
<![CDATA[
Client Server
CA CB SA SB
| | | |
+------->| | Header: GET (T=NON, Code=1, MID=0x7d38)
| GET | | Token: 0x53
| | | | Uri-Path: "temperature"
| | | | Response-To-Uri-Host: 10.1.1.1
| | | | Response-To-Uri-Port: 5683
| | | |
| |<-------+ Header: 2.05 Content (T=NON, Code=69, MID=0xad7b)
| | 2.05 | Token: 0x53
| | | | Payload: "22.3 C"
| | | |
]]>
</artwork>
</figure>
<!-- 1* CON, 1* NON -->
<figure anchor="msc_conA_ackA_nonB_separate" title="CON A, ACK A, NON B (separate)">
<artwork>
<![CDATA[
Client Server
CA CB SA SB
| | | |
+------->| | Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | | Token: 0x53
| | | | Uri-Path: "temperature"
| | | | Response-To-Uri-Host: 10.1.1.1
| | | | Response-To-Uri-Port: 5683
| | | |
|<-------+ | Header: (T=ACK, Code=0, MID=0x7d38)
| | | |
| |<-------+ Header: 2.05 Content (T=NON, Code=69, MID=0xad7b)
| | 2.05 | Token: 0x53
| | | | Payload: "22.3 C"
| | | |
]]>
</artwork>
</figure>
<figure anchor="msc_conA_ackB_nonB_separate" title="CON A, ACK B, NON B (separate)">
<!-- Illegal according to Klaus. -->
<artwork>
<![CDATA[
Client Server
CA CB SA SB
| | | |
+------->| | Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | | Token: 0x53
| | | | Uri-Path: "temperature"
| | | | Response-To-Uri-Host: 10.1.1.1
| | | | Response-To-Uri-Port: 5683
| | | |
| |<-------+ Header: (T=ACK, Code=0, MID=0x7d38)
| | | |
| |<-------+ Header: 2.05 Content (T=NON, Code=69, MID=0xad7b)
| | 2.05 | Token: 0x53
| | | | Payload: "22.3 C"
| | | |
]]>
</artwork>
</figure>
<!-- 1* CON, 1* ACK piggybacked -->
<figure anchor="msc_conA_ackA_piggybacked" title="CON A, ACK A">
<artwork>
<![CDATA[
Client Server
CA CB SA SB
| | | |
+------->| | Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | | Token: 0x53
| | | | Uri-Path: "temperature"
| | | | Response-To-Uri-Host: 10.1.1.1
| | | | Response-To-Uri-Port: 5683
| | | |
|<-------+ | Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38)
| 2.05 | | Token: 0x53
| | | | Payload: "22.3 C"
| | | |
]]>
</artwork>
</figure>
<figure anchor="msc_conA_ackB_piggybacked" title="CON A, ACK B">
<!-- Illegal according to Klaus. -->
<artwork>
<![CDATA[
Client Server
CA CB SA SB
| | | |
+------->| | Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | | Token: 0x53
| | | | Uri-Path: "temperature"
| | | | Response-To-Uri-Host: 10.1.1.1
| | | | Response-To-Uri-Port: 5683
| | | |
| |<-------+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38)
| | 2.05 | Token: 0x53
| | | | Payload: "22.3 C"
| | | |
]]>
</artwork>
</figure>
<!-- 1* NON, 1* CON -->
<figure anchor="msc_nonA_conB_ackB" title="NON A, CON B, ACK B">
<artwork>
<![CDATA[
Client Server
CA CB SA SB
| | | |
+------->| | Header: GET (T=NON, Code=1, MID=0x7d38)
| GET | | Token: 0x53
| | | | Uri-Path: "temperature"
| | | | Response-To-Uri-Host: 10.1.1.1
| | | | Response-To-Uri-Port: 5683
| | | |
| |<-------+ Header: 2.05 Content (T=CON, Code=69, MID=0x7d38)
| | 2.05 | Token: 0x53
| | | | Payload: "22.3 C"
| | | |
| +------->| Header: (T=ACK, Code=0, MID=0x7d38)
| | | |
]]>
</artwork>
</figure>
<!-- 2* CON -->
<figure anchor="msc_conA_ackA_conB_ackB_separate" title="CON A, ACK A, CON B, ACK B (separate)">
<artwork>
<![CDATA[
Client Server
CA CB SA SB
| | | |
+------->| | Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | | Token: 0x53
| | | | Uri-Path: "temperature"
| | | | Response-To-Uri-Host: 10.1.1.1
| | | | Response-To-Uri-Port: 5683
| | | |
|<-------+ | Header: (T=ACK, Code=0, MID=0x7d38)
| | | |
| |<-------+ Header: 2.05 Content (T=CON, Code=69, MID=0xad7b)
| | 2.05 | Token: 0x53
| | | | Payload: "22.3 C"
| | | |
| +------->| Header: (T=ACK, Code=0, MID=0xad7b)
| | | |
]]>
</artwork>
</figure>
<figure anchor="msc_conA_ackB_conB_ackB_separate" title="CON A, ACK B, CON B, ACK B (separate)">
<!-- Illegal according to Klaus. -->
<artwork>
<![CDATA[
Client Server
CA CB SA SB
| | | |
+------->| | Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | | Token: 0x53
| | | | Uri-Path: "temperature"
| | | | Response-To-Uri-Host: 10.1.1.1
| | | | Response-To-Uri-Port: 5683
| | | |
| |<-------+ Header: (T=ACK, Code=0, MID=0x7d38)
| | | |
| |<-------+ Header: 2.05 Content (T=CON, Code=69, MID=0xad7b)
| | 2.05 | Token: 0x53
| | | | Payload: "22.3 C"
| | | |
| +------->| Header: (T=ACK, Code=0, MID=0xad7b)
| | | |
]]>
</artwork>
</figure>
<!-- end of MSC comment -->
<!-- <t> -->
<!-- For piggy-backed response, message flow is depicted in <xref -->
<!-- target="pmsc" />. -->
<!-- </t> -->
<!-- <\!-- mab: the piggy-backed MSC seems wrong to me -\-> -->
<!-- <figure anchor="pmsc"> -->
<!-- <artwork> -->
<!-- <![CDATA[ -->
<!-- Client Address A (CA): tel:+1-201-555-0123 -->
<!-- Client Address B (CB): 10.1.1.1 -->
<!-- Server Address A (SA): tel:+1-201-555-0124 -->
<!-- Server Address B (SB): 10.1.1.2 -->
<!-- Client Server -->
<!-- CA CB SA SB -->
<!-- | | | | -->
<!-- | | | | -->
<!-- +------\->| | Header: GET (T=CON, Code=1, MID=0x7d38) -->
<!-- | GET | | Token: 0x53 -->
<!-- | | | | Uri-Path: "temperature" -->
<!-- | | | | Response-To-Uri-Host: 10.1.1.1 -->
<!-- | | | | Response-To-Uri-Port: 5683 -->
<!-- | | | | -->
<!-- | | | | -->
<!-- | |<-------+ Header: 2.05 Content (T=CON, Code=69, MID=0xad7b) -->
<!-- | | 2.05 | Token: 0x53 -->
<!-- | | | | Payload: "22.3 C" -->
<!-- | | | | -->
<!-- | | | | -->
<!-- | +------\->| Header: (T=ACK, Code=0, MID=0xad7b) -->
<!-- | | | | -->
<!-- ]]> -->
<!-- </artwork> -->
<!-- </figure> -->
<!-- <t> -->
<!-- For separate response, message flow is depicted in -->
<!-- <xref target="smsc" />. -->
<!-- </t> -->
<!-- <figure anchor="smsc"> -->
<!-- <artwork> -->
<!-- <![CDATA[ -->
<!-- Client Address A (CA): tel:+1-201-555-0123 -->
<!-- Client Address B (CB): 10.1.1.1 -->
<!-- Server Address A (SA): tel:+1-201-555-0124 -->
<!-- Server Address B (SB): 10.1.1.2 -->
<!-- Client Server -->
<!-- CA CB SA SB -->
<!-- | | | | -->
<!-- | | | | -->
<!-- +------\->| | Header: GET (T=CON, Code=1, MID=0x7d38) -->
<!-- | GET | | Token: 0x53 -->
<!-- | | | | Uri-Path: "temperature" -->
<!-- | | | | Response-To-Uri-Host: 10.1.1.1 -->
<!-- | | | | Response-To-Uri-Port: 5683 -->
<!-- | | | | -->
<!-- | |<-------+ Header: (T=ACK, Code=0, MID=0x7d38) -->
<!-- | | | | -->
<!-- | | | | -->
<!-- | |<-------+ Header: 2.05 Content (T=CON, Code=69, MID=0xad7b) -->
<!-- | | 2.05 | Token: 0x53 -->
<!-- | | | | Payload: "22.3 C" -->
<!-- | | | | -->
<!-- | | | | -->
<!-- | +------\->| Header: (T=ACK, Code=0, MID=0xad7b) -->
<!-- | | | | -->
<!-- ]]> -->
<!-- </artwork> -->
<!-- </figure> -->
</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 the 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="3gpp_ts_23_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="3gpp_ts_23_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 title="Message Exchange for USSD">
<t>
The message exchange for USSD is shown simplified in <xref
target="msc_ussd_mo" /> and <xref target="msc_ussd_mt"
/>. The communication between MS, MSC, VLR, HLR, and USSD-GW
is based on SS7 signalling and the communication between
USSD-GW is based on IP. Messages ending with _RPC are Remote
Procedure Calls (e.g. REST); messages without _RPC are SS7
signalling.
</t>
<t>
Message Sequence Charts with more details can be found in <xref target="3gpp_ts23_090" />.
</t>
<t>
In <xref target="msc_ussd_mo" /> the message sequence chart
for the USSD transport (Mobile Originated) is shown.
<figure align="center" anchor="msc_ussd_mo" title="CoAP Messages over USSD (Mobile Originated)">
<artwork> <![CDATA[
MS/CoAP CLIENT MSC/VLR/HLR/USSD-GW CoAP SERVER
| | |
| ---USSD_REQUEST--> | |
| | |
| | ---USSD_REQUEST_RPC--> |
| | <--USSD_RESPONSE_RPC-- |
| | |
| <--USSD_RESPONSE-- | |
| | |
]]> </artwork>
</figure>
</t>
<t>
In <xref target="msc_ussd_mt" /> the message sequence chart
for the USSD transport (Mobile Terminated) is shown.
<figure align="center" anchor="msc_ussd_mt" title="CoAP Messages over USSD (Mobile Terminated)">
<artwork> <![CDATA[
MS/CoAP SERVER MSC/VLR/HLR/USSD-GW CoAP CLIENT
| | |
| | <--USSD_REQUEST_RPC--- |
| | |
| <--USSD_REQUEST--- | |
| ---USSD_RESPONSE-> | |
| | |
| | ---USSD_RESPONSE_RPC-> |
| | |
]]> </artwork>
</figure>
</t>
</section>
</section>
<section title="Encoding of CoAP for non-IP transports">
<section title="Encoding of CoAP for SMS transport" anchor="sms_encoding">
<t>The content of a short message 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 short message
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 short
message encoding.</t>
<t>16 bit encoding: CoAP binary data needs to be
re-encoded. Not all telematic devices support 16 bit short
message encoding.</t>
</list>
<!--
The currently safest solution is to use 7 bit encoded SMS
including Base64 encoded CoAP payload.
-->
</t>
<t>
More considerations about SMS encoding can be found in
<xref target="I-D.bormann-coap-misc" />.
</t>
</section>
<section title="Encoding of CoAP for USSD transport">
<t>
The encoding of USSD data is identical to the encoding of short
messages.
</t>
</section>
</section>
<section title="Message Size Implementation Considerations">
<t>Using 7 bit encoding 160 characters are allowed in 1 short
message, 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 short message concatenation</t>
<t>CoAP Block <xref target="I-D.ietf-core-block" /></t>
</list>
It is RECOMMENDED that SMS is not used to transfer very large
resource data using Blocks.
</t>
<t>
There is no possibility to concatenate messages with USSD, thus
the only option would be CoAP Block is necessary.
</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>
<t>
For mobile-originated USSD the addressing is done by a so called
application numbers.
</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="I-D.ietf-core-coap" />, 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="I-D.ietf-core-coap" />
</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="I-D.ietf-core-coap"
/>.
</t>
<section anchor="options" title="New Options for mixed IP/non-IP operation.">
<t>
When CoAP should be used in mixed IP and non-IP mode
(e.g. SMS/USSD and GPRS as in <xref
target="cell2cell_sms_gprs" /> and <xref
target="ip2cell_sms_gprs" />) 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>
<texttable anchor="table_coap_option" title="New CoAP Option Numbers">
<ttcol align="center">No.</ttcol>
<ttcol align="center">C</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>30</c>
<c></c>
<c></c>
<c>Response-To-Uri-Host</c>
<c>string</c>
<c>1-270 B</c>
<c>(none)</c>
<c>32</c>
<c></c>
<c></c>
<c>Response-To-Uri-Port</c>
<c>uint</c>
<c>0-2 B</c>
<c>5683</c>
<!--
<c>TBD</c>
<c>E</c>
<c>Response-To-Tel</c> mab: For mobile clients this might be needed?
<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/USSD.
The URI scheme for CoAP over SMS/USSD is derived from the CoAP
scheme in <xref target="I-D.ietf-core-coap" />.
As there is no host and port available for the SMS/USSD
transport, those parts are replaced with the
"telephone-subscriber" from <xref target="RFC3966" />.
</t>
<!--
NOTE: possible schemes: sms:// (RFC5724), tel:// (RFC 3966),
smpp:// (draft-yu-enumservice-sms-smpp-01) )
-->
<!--
NOTE: what about USSD?
coap+sms:// some excludes USSD, therefore I would prefer coap+tel://
-->
<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 type="abnf"> -->
<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>
<!-- TODO: check this with an ABNF compiler -->
</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="I-D.ietf-core-coap" /> for the applications described
here. The actual value SHOULD be chosen based on experience
with SMS, USSD and GPRS.
</t>
</section>
<section title="Multicast">
<t>Multicast is not possible with SMS and USSD transports.
<!--
Multicast MUST NOT be used with the SMS and USSD transports.
-->
</t>
</section>
<section anchor="proxy" title="Proxying Considerations">
<t>
In case of non-IP transport, several use cases might arise for proxies:
<list style="symbols">
<t>For a CoAP IP Client and a Mobile Terminated CoAP Server:
An HTTP-CoAP Proxy at the mobile network / IP network border.</t>
<t>For a Mobile Originated CoAP Client and (CoAP/HTTP) IP Server:
A CoAP-CoAP or CoAP-HTTP Proxy at the mobile network and IP
network border or in the server network.</t>
<t>If an LLN is attached to the Mobile: A CoAP-CoAP Proxy
into the LLN.</t>
</list>
</t>
<t>
In <xref target="arch" /> a typical M2M scenario is shown
where a User (U) is connected by an IP network to an M2M
service provider (M). Over a cellular network the M2M
telematic device (T) is attached. Possibly a constrained
network is attached to the telematic device.
<figure align="center" anchor="arch" title="M2M architecture">
<artwork align="center"><![CDATA[
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
]]></artwork>
</figure>
In sections <xref target="mts_sec" /> to <xref target="mc_sec"
/> several combinations of CoAP and HTTP clients, servers and
proxies are shown. The various cases are not distinct but can be
mixed to meet the M2M requirements.
</t>
<!-- =============================== -->
<section anchor="mts_sec" title="Mobile Telematic Server">
<figure align="center" anchor="arch_mts_A" title="M2M architecture (Mobile Telematic Server) A">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| |
C-C C-S
]]></artwork>
</figure>
<figure align="center" anchor="arch_mts_B" title="M2M architecture (Mobile Telematic Server) B">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-C-P: CoAP-CoAP Proxy (Forward Proxy)
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | |
C-C C-C-P C-S
]]></artwork>
</figure>
<figure align="center" anchor="arch_mts_C" title="M2M architecture (Mobile Telematic Server) C">
<artwork align="center"><![CDATA[
H-C: HTTP Client
H-C-P: HTTP-CoAP Proxy (Forward Proxy)
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | |
H-C H-C-P C-S
]]></artwork>
</figure>
</section>
<!-- =============================== -->
<section title="Mobile Telematic Client">
<figure align="center" anchor="arch_mtc_A" title="M2M architecture (Mobile Telematic Client) A">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| |
C-S C-C
]]></artwork>
</figure>
<figure align="center" anchor="arch_mtc_B" title="M2M architecture (Mobile Telematic Client) B">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-C-P: CoAP-CoAP Proxy (Forward Proxy)
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | |
C-S C-C-P C-C
]]></artwork>
</figure>
<figure align="center" anchor="arch_mtc_C" title="M2M architecture (Mobile Telematic Client) C">
<artwork align="center"><![CDATA[
C-C: CoAP Client
H-C-P: HTTP-CoAP Proxy (Forward Proxy)
H-S: HTTP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | |
H-S H-C-P C-C
]]></artwork>
</figure>
</section>
<!-- =============================== -->
<section title="Mobile Server">
<figure align="center" anchor="arch_ms_A" title="M2M architecture (Mobile Server) A">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| |
C-C C-S
]]></artwork>
</figure>
<figure align="center" anchor="arch_ms_B" title="M2M architecture (Mobile Server) B">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-C-P: CoAP-CoAP Proxy (Forward Proxy)
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | |
C-C C-C-P C-S
]]></artwork>
</figure>
<figure align="center" anchor="arch_ms_C" title="M2M architecture (Mobile Server) C">
<artwork align="center"><![CDATA[
H-C: HTTP Client
H-C-P: HTTP-CoAP Proxy (Cross-Protocol Forward Proxy)
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | |
H-C H-C-P C-S
]]></artwork>
</figure>
<figure align="center" anchor="arch_ms_D" title="M2M architecture (Mobile Server) D">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-C-P1: CoAP-CoAP Proxy (Forward Proxy)
C-C-P2: CoAP-CoAP Proxy (Mirror Proxy)
C-S: CoAP Server (actually Clients which PUT to C-C-P2)
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | | |
C-C C-C-P1 C-C-P2 C-S
]]></artwork>
</figure>
</section>
<!-- =============================== -->
<section anchor="mc_sec" title="Mobile Client">
<figure align="center" anchor="arch_mc_A" title="M2M architecture (Mobile Client) A">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| |
C-S C-C
]]></artwork>
</figure>
<figure align="center" anchor="arch_mc_B" title="M2M architecture (Mobile Client) B">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-C-P: CoAP-CoAP Proxy (Reverse Proxy)
C-S: CoAP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | |
C-S C-C-P C-C
]]></artwork>
</figure>
<figure align="center" anchor="arch_mc_C" title="M2M architecture (Mobile Client) C">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-C-P1: CoAP-CoAP Proxy (Forward Proxy)
C-C-P2: CoAP-CoAP Proxy (Mirror Proxy)
C-S: CoAP Server (actually Clients which PUT to C-C-P2)
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | | |
C-S C-C-P2 C-C-P1 C-C
]]></artwork>
</figure>
<figure align="center" anchor="arch_mc_D" title="M2M architecture (Mobile Client) D">
<artwork align="center"><![CDATA[
C-C: CoAP Client
C-C-P: CoAP-CoAP Proxy (Forward Proxy)
H-C-P: HTTP-CoAP Proxy (Mirror Proxy)
H-S: HTTP Server
+---+ *-----* +---+ *--------* +---+ *-----------*
| | / IP \ | | / cellular \ | | / constrained \
| U |-| network |-| M |-| network |-| T |-| network |
| | \ / | | \ / | | \ /
+---+ *-----* +---+ *--------* +---+ *-----------*
| | | |
H-S H-C-P C-C-P C-C
]]></artwork>
</figure>
</section>
</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="3gpp_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 |
+--------+----------------------+----------------------------+
| 30 | Response-To-Uri-Host | Section 2 of this document |
+--------+----------------------+----------------------------+
| 32 | Response-To-Uri-Port | Section 2 of this document |
+--------+----------------------+----------------------------+
</artwork>
</figure>
</section>
<section anchor="IANA_scheme" title="URI Scheme Registration">
<t>
This document requests the registration of the Uniform
Resource Identifier (URI) scheme "coap+tel". 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;-->
&I-D.ietf-core-coap;
&I-D.ietf-core-block;
&I-D.bormann-coap-misc;
<!-- coding scheme: SMS, USSD -->
<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>
<!--
<reference anchor="3gpp_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="3gpp_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="3gpp_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>
-->
<!-- USSD -->
<!--
<reference anchor="3gpp_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="3gpp_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="3gpp_ts_23_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="3gpp_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>
</references>
<section anchor="app-additional" title="Changelog">
<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. <xref target="urischeme" /></t>
<t>Added possible CON/NON/ACK interactions. <xref target="comm_examples" /></t>
<t>Added possible M2M proxy scenarios. <xref target="proxy" /></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://. <xref target="opt_uri" /></t>
<t>Chose CoAP option numbers and updated the option number table
to meet draft-ietf-core-coap-10. <xref target="table_coap_option"
/></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:40 |