One document matched: draft-becker-core-coap-sms-gprs-01.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-01" 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 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) 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 GPRS, HSPA or LTE.
</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 SMS are normally stored in the 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 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 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 an SMS 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 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 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 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 an SMS, 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 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 SMS
message, and the CoAP Server works as another Mobile Station
to receive the SMS message. All the SMS 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">
<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="Encoding of CoAP for USSD transport">
<t>
The encoding of USSD data is identical to the encoding of SMS.
</t>
</section>
</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>
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 SMS 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 title="Options">
<t>
Uri-Host: The Uri-Host option SHOULD only be sent, in case of
proxying. If no proxying is intended the option SHOULD NOT BE
set.
</t>
<t>
Uri-Port: The Uri-Host option SHOULD only be sent, in case of
proxying. If no proxying is intended the option SHOULD NOT BE
set.
</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 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 other address that should be used for the CoAP
response. For this reason the new options Reply-To-Uri-Host
and Reply-To-Uri-Port are proposed.
</t>
<t>
OPEN QUESTION: Are CoAP user option numbers applicable here?
</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>TBD</c>
<c>Critical</c>
<c>Reply-To-Uri-Host</c>
<c>string</c>
<c>1-270 B</c>
<c>(none)</c>
<c>TBD</c>
<c>Critical</c>
<c>Reply-To-Uri-Port</c>
<c>uint</c>
<c>0-2 B</c>
<c>5683</c>
</texttable>
</section>
</section>
<section title="Protocol Constants">
<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 MUST NOT be used with the SMS and USSD transports.</t>
</section>
<section 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>
</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="IANA" title="IANA Considerations">
<t>This memo currently includes no request to IANA. If
Reply-To-Uri-Host and Reply-To-Uri-Port are deemed useful and
decision is taken not to have CoAP user options, it might
include IANA requests.
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Security mechanisms defined in <xref target="3gpp_ts23_888" />
are used to guarantee transport security.
</t>
<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 a 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>
</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 and Nils Schulte for the
discussion.
</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;
<!-- 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="Additional Stuff"> -->
<!-- <t>This becomes an Appendix.</t> -->
<!-- </section> -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:38:03 |