[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

CoRE                                                      M. Becker, Ed.
Internet-Draft                           ComNets, TZI, University Bremen
Intended status: Standards Track                                   K. Li
Expires: February 9, 2015                            Huawei Technologies
                                                          K. Kuladinithi
                                                              T. Poetsch
                                         ComNets, TZI, University Bremen
                                                          August 8, 2014


                       Transport of CoAP over SMS
                   draft-becker-core-coap-sms-gprs-05

Abstract

   Short Message Service (SMS) of mobile cellular networks is frequently
   used in Machine-To-Machine (M2M) communications, such as for
   telematic devices.  The service offers small packet sizes and high
   delays just as other typical low-power and lossy networks (LLNs),
   i.e. 6LoWPANs.  The design of the Constrained Application Protocol
   (CoAP) [RFC7252], that took the limitations of LLNs into account, is
   thus also applicable to other transports.  The adaptation of CoAP to
   SMS transport mechanisms is described in this document.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 9, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Becker, et al.          Expires February 9, 2015                [Page 1]


Internet-Draft                CoAP over SMS                  August 2014


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   4.  Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  MO-MT Scenarios . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  MT Scenarios  . . . . . . . . . . . . . . . . . . . . . .   4
     4.3.  MO Scenarios  . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Message Exchanges . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Message Exchange for SMS in a Cellular-To-Cellular
           Mobile-Originated and Mobile-Terminated Scenario  . . . .   6
   6.  Encoding Schemes of CoAP for SMS transport  . . . . . . . . .   7
   7.  Message Size Implementation Considerations  . . . . . . . . .   7
   8.  Addressing  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Options . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  New Options for mixed IP operation. . . . . . . . . . . .   8
   10. URI Scheme  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   11. Transmission Parameters . . . . . . . . . . . . . . . . . . .   9
   12. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   13. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     14.1.  CoAP Option Number . . . . . . . . . . . . . . . . . . .  10
     14.2.  URI Scheme Registration  . . . . . . . . . . . . . . . .  10
   15. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     16.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Appendix A.  Changelog  . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   This specification details the usage of the Constrained Application
   Protocol on the Short Message Service (SMS) of mobile cellular
   networks.






Becker, et al.          Expires February 9, 2015                [Page 2]


Internet-Draft                CoAP over SMS                  August 2014


1.1.  Motivation

   In some M2M environments, internet connectivity is not supported by
   the constrained end-points, but a cellular network connection is
   supported instead.  Internet connectivity might also be switched off
   for power saving reasons or the cellular coverage does not allow for
   Internet connectivity.  In these situations, SMS will be supported,
   instead of UDP/IP over General Packet Radio Service (GPRS), High
   Speed Packet Access (HSPA) or Long Term Evolution (LTE) networks.

   In 3GPP, SMS is identified as the transport protocol for small data
   transmissions (See [ts23_888] for Key Issue on Machine Type
   Communication (MTC) Device Trigger and the proposed solutions in
   Sections 6.2, 6.42, 6.44, 6.48, 6.52, 6.60, and 6.61).  In [ts23_682]
   'Architecture Enhancements to facilitate communications with Packet
   Data Networks and Applications' SMS is at the moment the only Trigger
   Delivery (Trigger Delivery using T4).

   M2M protocols using SMS, e.g. for telematics, are using mostly
   various diverse proprietary and closed binary protocols with limited
   publicly available documentation at the moment.

   In Open Mobile Alliance (OMA) LightweightM2M technical specification
   [oma_lightweightm2m_ts], SMS is identified as an alternative
   transport for CoAP messages.

2.  Terminology

   This document uses the following terminology:

   CoAP Server and Client
      The terms CoAP Server and CoAP Client are used synonymously to
      Server and Client as specified in the terminology section of
      [RFC7252].

   Mobile Station (MS)
      A Mobile Station includes all required user equipment and software
      that is needed for communication with a mobile network.  As
      defined in [etsi_ts101_748].

3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].






Becker, et al.          Expires February 9, 2015                [Page 3]


Internet-Draft                CoAP over SMS                  August 2014


4.  Scenarios

   Several scenarios are presented first for M2M communications with
   CoAP over SMS.  First Mobile-Originating Mobile-Terminating (MO-MT)
   scenarios are presented, where both CoAP endpoints are in devices in
   a cellular network.  Next, Mobile-Terminating (MT) scenarios are
   detailed, where only the CoAP server is in a cellular network.
   Finally, Mobile-Originating (MO) scenarios where the CoAP client is
   in the cellular network.

4.1.  MO-MT Scenarios

   Two mobile cellular terminals communicate by exchanging a CoAP
   Request and Response embedded into short message protocol data units
   (PDUs) (depicted in Figure 1).  Both terminals are connected via a
   Short Message Service Centre (SMS-C).

                       CoAP-REQ            CoAP-REQ
              +------+   (SMS)   +-------+   (SMS)  +------+
              |  A   | --------> | SMS-C | -------> |  B   |
              |(cell)| <-------- |       | <------- |(cell)|
              +------+ CoAP-RES  +-------+ CoAP-RES +------+
                         (SMS)               (SMS)

      Figure 1: Cellular and Cellular Communication (only SMS-based)

4.2.  MT Scenarios

   An IP host and a mobile cellular terminal communicate by exchanging
   CoAP Request and Response.  The IP host uses protocols offered by the
   SMS-C (e.g.  Short Message Peer-to-Peer (SMPP [smpp]), Computer
   Interface to Message Distribution (CIMD [cimd]), Universal Computer
   Protocol/External Machine Interface (UCP/EMI [ucp])) to submit a
   short message for delivery, which contains the CoAP Request (depicted
   in Figure 2).

                        CIMD               CoAP-REQ
             +------+   SMPP    +-------+    (SMS)   +------+
             |  A   | --------> | SMS-C | ---------> |  B   |
             | (IP) | <-------- |       | <--------- |(cell)|
             +------+           +-------+  CoAP-RES  +------+
                                             (SMS)

                  Figure 2: IP and Cellular Communication

   There are service providers that offer SMS delivery and notification
   using an HTTP/REST interface (depicted in Figure 3).




Becker, et al.          Expires February 9, 2015                [Page 4]


Internet-Draft                CoAP over SMS                  August 2014


             HTTP-REQ                 CIMD            CoAP-REQ
   +------+ (CoAP-DATA) +----------+  SMPP   +-----+    (SMS)   +------+
   |      |             | SMS      |  SS7    |SMS-C|            |      |
   |  A   | ----------> | Service  | ------> |  /  | ---------> |  B   |
   | (IP) | <---------- | Provider | <------ | HLR | <--------- |(cell)|
   +------+  HTTP-RES   +----------+         +-----+  CoAP-RES  +------+
            (CoAP-DATA)                                 (SMS)

       Figure 3: IP and Cellular Communication (using an SMS Service
                                 Provider)

4.3.  MO Scenarios

   A mobile cellular terminal and an IP host communicate by exchanging
   CoAP Request and Response.  The mobile cellular terminal sends a CoAP
   Request in a short message, which is in turn forwarded by the SMS-C
   (e.g. with Short Message Peer-to-Peer (SMPP [smpp]), Computer
   Interface to Message Distribution (CIMD [cimd]), Universal Computer
   Protocol/External Machine Interface (UCP/EMI [ucp])) as depicted in
   Figure 4).  This scenario can be a fall-back for mobile-originating
   communication, when IP connectivity cannot be setup (e.g. due to
   missing coverage).

                       CoAP-REQ              CIMD
             +------+   (SMS)   +-------+    SMPP    +------+
             |  A   | --------> | SMS-C | ---------> |  B   |
             |(cell)| <-------- |       | <--------- | (IP) |
             +------+  CoAP-RES +-------+            +------+
                       (SMS)

                  Figure 4: Cellular and IP Communication

   There are service providers offering SMS delivery and notification
   using an HTTP/REST interface (depicted in Figure 5).

             CoAP-REQ             CIMD                HTTP-REQ
   +------+   (SMS)    +-------+  SMPP  +----------+ (CoAP-DATA) +----+
   |      |            | SMS-C |  SS7   | SMS      |             |    |
   |  A   | ---------> |   /   | -----> | Service  | ----------> | B  |
   |(cell)| <--------- |  HLR  | <----- | Provider | <---------- |(IP)|
   +------+  CoAP-RES  +-------+        +----------+  HTTP-RES   +----+
              (SMS)                                  (CoAP-DATA)

       Figure 5: IP and Cellular Communication (using an SMS Service
                                 Provider)






Becker, et al.          Expires February 9, 2015                [Page 5]


Internet-Draft                CoAP over SMS                  August 2014


5.  Message Exchanges

5.1.  Message Exchange for SMS in a Cellular-To-Cellular Mobile-
      Originated and Mobile-Terminated Scenario

   The CoAP Client works as a Mobile Station to send the short message,
   and the CoAP Server works as another Mobile Station to receive the
   short message.  All short messages are stored and forwarded by the
   Service Center.  The message exchange between the CoAP Client and the
   CoAP Server is depicted in the figure below:

    MS/CoAP CLIENT        Service Center          MS/CoAP SERVER
        |                       |                        |
        |   ---SMS-SUBMIT--->   |                        |
        | <-SMS-SUBMIT-REPORT-- |                        |
        |                       |                        |
        |                       |    --SMS-DELIVER--->   |
        |                       | <-SMS-DELIVER-REPORT-- |
        |                       |                        |
        | <-SMS-STATUS-REPORT-- |                        |
        |                       |                        |


                     Figure 6: CoAP Messages over SMS

   Note that the message exchange is just for one request message from
   CoAP Client and CoAP Server.  It includes the following steps:

   Step 1: The CoAP Client sends a CoAP request in a SMS-SUBMIT message
   to the Service Center.  The CoAP Server address is specified as TP-
   Destination-Address (see [ts23_040]).

   Step 2: The Service Center returns a SMS-SUBMIT-REPORT message to the
   CoAP Client.

   Step 3: The Service Center stores the received SMS message and
   forwards it to the CoAP Server, using an SMS-DELIVER message.  The
   CoAP Client address is specified as a TP Originating Address (see
   [ts23_040]).

   Step 4: The CoAP Server returns an SMS-DELIVER-REPORT message to the
   Service Center.

   Step 5: The Service Center returns the SMS-STATUS-REPORT message to
   the CoAP Client to indicate the SMS delivery status, if required by
   the CoAP Client.





Becker, et al.          Expires February 9, 2015                [Page 6]


Internet-Draft                CoAP over SMS                  August 2014


   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.

6.  Encoding Schemes of CoAP for SMS transport

   Short messages can be encoded by using various alphabets: GSM 7 bit
   default alphabet ([ts23_038]), 8 bit data alphabet, and 16 bit USC2
   data alphabet ([iso_ucs2]).  These encodings lead to message sizes of
   160, 140, and 70 characters, respectively.  Whereas the support of 7
   bit encoding is mandatory on a MS, the two other encodings are
   dependent on the language that needs to be encoded, e.g.  USC2 for
   Arabic, Chinese, Japanese, etc.  Furthermore, the supported encoding
   highly depends on the implementations of the MS itself.

   According to [ts23_038], GSM 7 bit encoding shall be supported by all
   MSs offering SMS services.  Since not all MSs support 8 bit short
   message encoding, the prefered encoding scheme for CoAP messages over
   SMS is therefore 7 bit, e.g.  Base64 ([RFC4648]) or SMS encoding in
   [I-D.bormann-coap-misc].

   More considerations about SMS encoding can be found in
   [I-D.bormann-coap-misc].

7.  Message Size Implementation Considerations

   By using 7 bit encoding, a maximum length of 160 characters is
   allowed in one short message [ts23_038].  Consequently, the maximum
   length for a CoAP message results in 140 bytes. 160 characters = (140
   bytes * 8)/7.

   Possible options for larger CoAP messages are:

   Concatenated short messages
      Most MSs are able to send concatenation short messages in order to
      tranmsit longer messages.  The total length of a concatenated
      short message can consist of up to 255 single messages and result
      in total length of 39015 7 bit characters or 34170 bytes.
      Resulting from this, the maximum length of each individual message
      reduces to 153 (160 - 7) characters (133 bytes).

   CoAP blockwise transfer
      According to [I-D.ietf-core-block], the Block Size (SZX) of
      blockwise transfer in CoAP is represented as a three-bit unsigned
      integer.  Thus, the possible block sizes are to the power of two.
      (Block size = 2**(SZX + 4)).  Due to the limitations of 160



Becker, et al.          Expires February 9, 2015                [Page 7]


Internet-Draft                CoAP over SMS                  August 2014


      characters (140 bytes) for one short message, the maximum value of
      SZX is 3 (Block size = 128 byte).

   However, it is RECOMMENDED that SMS is not used to transfer very
   large resource data using blockwise transfer.

8.  Addressing

   For SMS in cellular networks, the CoAP endpoints have to work with a
   SIM (Subscriber Identity Module) card and have to be addressed by the
   MSISDN (Mobile Station ISDN (MSISDN) number).

   To allow the CoAP client to detect that the short message contains a
   CoAP message, the TP-DATA-Coding-Scheme SHOULD be included.

9.  Options

9.1.  New Options for mixed IP operation.

   In case a CoAP Server has more than one network interface, e.g.  SMS
   and IP, the CoAP Client might want the server to send the response
   via an alternative transport, i.e. to it's alternative address.
   However, that implies that the initiating CoAP Client is aware of the
   presence of the alternative interface.  For this reason the new
   options Response-To-Uri-Host and Response-To-Uri-Port are proposed.

   +----+---+---+---+---+-------------------+-------+--------+---------+
   | No | C | U | N | R |        Name       | Forma | Length | Default |
   | .  |   |   |   |   |                   |   t   |        |         |
   +----+---+---+---+---+-------------------+-------+--------+---------+
   | TB |   |   |   |   |  Response-To-Uri- | strin | 1-270  |  (none) |
   | D  |   |   |   |   |        Host       |   g   |   B    |         |
   | TB |   |   |   |   |  Response-To-Uri- |  uint | 0-2 B  |   5683  |
   | D  |   |   |   |   |        Port       |       |        |         |
   +----+---+---+---+---+-------------------+-------+--------+---------+

                     Table 1: New CoAP Option Numbers

   If the Response-To-Uri-Host is present in the request, server MUST
   send the response to the indicated URI address, instead of the
   client's original request URI.

   The options SHOULD NOT be used in the response.

   The options MUST NOT occur more than once.






Becker, et al.          Expires February 9, 2015                [Page 8]


Internet-Draft                CoAP over SMS                  August 2014


10.  URI Scheme

   The coap:// scheme defines that a CoAP server is reachable over UDP/
   IP.  Hence, a new URI scheme is needed for CoAP servers which are
   reachable over SMS.

   As specified in [I-D.silverajan-core-coap-alternative-transports],
   the transport information is expressed as part of the URI scheme
   component.  This is performed by minting new schemes for SMS
   transport using the form "coap+sms", where the name of the transport
   is clearly and unambiguously described.  The endpoint identifier,
   path and query components together with each scheme name would be
   used to uniquely identify each resource.

   Example of such URI :

   o coap+sms://0015105550101/sensors/temperature

   In the URI, 0015105550101 is a telephone subscriber number.

11.  Transmission Parameters

   It is RECOMMENDED to configure the RESPONSE_TIMEOUT variable for a
   higher duration than specified in [RFC7252] for the applications
   described here.  The actual value SHOULD be chosen based on
   experience with SMS .

12.  Multicast

   Multicast is not possible with SMS transports.

13.  Security Considerations

   It is possible that a malicious CoAP Client sends repeated requests,
   and it may cost money for the CoAP Server to use SMS to send back
   associated responses.  To avoid this situation, the CoAP Server
   implementation can authenticate the CoAP Client before responding to
   the requests.  For example, the CoAP Server can maintain an MSISDN
   white list.  Only the MSISDN specified in the white list will be
   allowed to send requests.  The requests from others will be ignored
   or rejected.

14.  IANA Considerations








Becker, et al.          Expires February 9, 2015                [Page 9]


Internet-Draft                CoAP over SMS                  August 2014


14.1.  CoAP Option Number

   The IANA is requested to add the following option number entries to
   the CoAP Option Number Registry:

      +--------+----------------------+----------------------------+
      | Number |       Name           | Reference                  |
      +--------+----------------------+----------------------------+
      |  TBD   | Response-To-Uri-Host | Section 2 of this document |
      +--------+----------------------+----------------------------+
      |  TBD   | Response-To-Uri-Port | Section 2 of this document |
      +--------+----------------------+----------------------------+

14.2.  URI Scheme Registration

   According to [I-D.silverajan-core-coap-alternative-transports] this
   document requests the registration of the Uniform Resource Identifier
   (URI) scheme "coap+alt".  The registration request complies with
   [RFC4395].

15.  Acknowledgements

   This document is partly based on research for the research project
   'The Intelligent Container' which is supported by the Federal
   Ministry of Education and Research, Germany, under reference number
   01IA10001.

   The authors of this draft would like to thank Bert Greevenbosch,
   Marcus Goetting, Nils Schulte and Klaus Hartke for the discussions on
   the topic and the reviews of this document.

16.  References

16.1.  Normative References

   [I-D.bormann-coap-misc]
              Bormann, C. and K. Hartke, "Miscellaneous additions to
              CoAP", draft-bormann-coap-misc-26 (work in progress),
              December 2013.

   [I-D.ietf-core-block]
              Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
              draft-ietf-core-block-15 (work in progress), July 2014.

   [I-D.silverajan-core-coap-alternative-transports]
              Silverajan, B. and T. Savolainen, "CoAP Communication with
              Alternative Transports", draft-silverajan-core-coap-
              alternative-transports-06 (work in progress), July 2014.



Becker, et al.          Expires February 9, 2015               [Page 10]


Internet-Draft                CoAP over SMS                  August 2014


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers", RFC
              3966, December 2004.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

   [etsi_ts101_748]
              ETSI, "Technical Report: Digital cellular
              telecommunications system; Abbreviations and acronyms (GSM
              01.04 version 8.0.0 release 1999)", 2000.

   [iso_ucs2]
              ISO, "ISO/IEC10646: "Universal Multiple-Octet Coded
              Character Set (UCS)"; UCS2, 16 bit coding.", 2000.

   [ts23_038]
              ETSI 3GPP, "Technical Specification: Alphabets and
              language-specific information (3GPP TS 23.038 version
              11.0.0 Release 11)", 2012.

16.2.  Informative References

   [cimd]     Nokia, "CIMD Interface Specification (SMSCDOC8000.00,
              Nokia SMS Center 8.0)", 2005.

   [oma_lightweightm2m_ts]
              OMA, "Lightweight Machine to Machine Technical
              Specification", 2013.

   [smpp]     SMPP Developers Forum, "Short Message Peer to Peer
              Protocol Specification v3.4 Issue 1.2", 1999.

   [ts23_040]
              3GPP, "Technical realization of the Short Message Service
              (SMS)", 3GPP-23.040 a00, Mar 2011.



Becker, et al.          Expires February 9, 2015               [Page 11]


Internet-Draft                CoAP over SMS                  August 2014


   [ts23_682]
              ETSI 3GPP, "Technical Specification Group Services and
              System Aspects; Architecture Enhancements to facilitate
              communications with Packet Data Networks and Applications;
              (Release 11)", 2012.

   [ts23_888]
              ETSI 3GPP, "Technical Specification Group Services and
              System Aspects; System Improvements for Machine-Type
              Communications; (3GPP TR 23.888 version 1.6.0, Release
              11)", 2011.

   [ucp]      Vodafone, "Short Message Service Centre (SMSC) External
              Machine Interface (EMI) Description Version 4.3d", 2011.

Appendix A.  Changelog

   Changed from draft-04 to draft-05:

   o  Removed reference to USSD.

   o  Updated reference to RFC7252 and 3GPP specs.

   o  Updated Options.

   o  Adapted URI scheme.

   Changed from draft-03 to draft-04:

   o  Removed USSD and GPRS related parts.

   o  Removed section 5: Examples

   o  Removed section 14: Proxying Considerations

   o  Added more block size considerations.

   o  Added more concatenated SMS considerations.

   o  Rewrote encoding scheme section; 7 bit encoding only.

   Changed from draft-02 to draft-03:

   o  Added reference to OMA LightweightM2M Technical Specification in
      "Motivation" section.

   o  Chose CoAP option numbers and updated the option number table to
      meet draft-ietf-core-coap-13.



Becker, et al.          Expires February 9, 2015               [Page 12]


Internet-Draft                CoAP over SMS                  August 2014


   Changed from draft-01 to draft-02:

   o  Added security considerations: Transport and Object Security.
      Section 13

   o  Reply-To-* changed to Response-To-*. Section 14

   o  Added URI scheme.

   o  Added possible CON/NON/ACK interactions.

   o  Added possible M2M proxy scenarios.

   o  Added reference to bormann-coap-misc for other SMS encoding.
      Section 6

   o  Updated requirements on Uri-Host and Uri-Port for coap+tel://.

   o  Chose CoAP option numbers and updated the option number table to
      meet draft-ietf-core-coap-10.  />

   o  Added an IANA registration for the URI scheme.  Section 14.2

Authors' Addresses

   Markus Becker (editor)
   ComNets, TZI, University Bremen
   Bibliothekstrasse 1
   Bremen  28359
   Germany

   Phone: +49 421 218 62379
   Email: mab@comnets.uni-bremen.de


   Kepeng Li
   Huawei Technologies
   Huawei Base, Bantian, Longgang District
   Shenzhen, Guangdong  518129
   P. R. China

   Phone: +86-755-28974289
   Email: likepeng@huawei.com








Becker, et al.          Expires February 9, 2015               [Page 13]


Internet-Draft                CoAP over SMS                  August 2014


   Koojana Kuladinithi
   ComNets, TZI, University Bremen
   Bibliothekstrasse 1
   Bremen  28359
   Germany

   Phone: +49 421 218 62382
   Email: koo@comnets.uni-bremen.de


   Thomas Poetsch
   ComNets, TZI, University Bremen
   Bibliothekstrasse 1
   Bremen  28359
   Germany

   Phone: +49 421 218 62379
   Email: thp@comnets.uni-bremen.de

































Becker, et al.          Expires February 9, 2015               [Page 14]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/