[Docs] [txt|pdf] [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: August 9, 2013                              Huawei Technologies
                                                          K. Kuladinithi
                                                              T. Poetsch
                                         ComNets, TZI, University Bremen
                                                        February 5, 2013


               Transport of CoAP over SMS, USSD and GPRS
                   draft-becker-core-coap-sms-gprs-03

Abstract

   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.

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 August 9, 2013.

Copyright Notice

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




Becker, et al.           Expires August 9, 2013                 [Page 1]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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.










































Becker, et al.           Expires August 9, 2013                 [Page 2]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  5
   4.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  MO-MT Scenarios  . . . . . . . . . . . . . . . . . . . . .  5
     4.2.  MT Scenarios . . . . . . . . . . . . . . . . . . . . . . .  6
     4.3.  MO Scenarios . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Message Exchanges  . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Message Exchange for SMS in a Cellular-To-Cellular
           Mobile-Originated and Mobile-Terminated Scenario . . . . . 13
     6.2.  Message Exchange for USSD  . . . . . . . . . . . . . . . . 14
   7.  Encoding of CoAP for non-IP transports . . . . . . . . . . . . 15
     7.1.  Encoding of CoAP for SMS transport . . . . . . . . . . . . 15
     7.2.  Encoding of CoAP for USSD transport  . . . . . . . . . . . 16
   8.  Message Size Implementation Considerations . . . . . . . . . . 16
   9.  Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   10. Options  . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. New Options for mixed IP/non-IP operation. . . . . . . . . 17
   11. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . 17
       11.1.1.  Formal Definition . . . . . . . . . . . . . . . . . . 18
       11.1.2.  Example . . . . . . . . . . . . . . . . . . . . . . . 18
   12. Transmission Parameters  . . . . . . . . . . . . . . . . . . . 18
   13. Multicast  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   14. Proxying Considerations  . . . . . . . . . . . . . . . . . . . 18
     14.1. Mobile Telematic Server  . . . . . . . . . . . . . . . . . 19
     14.2. Mobile Telematic Client  . . . . . . . . . . . . . . . . . 20
     14.3. Mobile Server  . . . . . . . . . . . . . . . . . . . . . . 21
     14.4. Mobile Client  . . . . . . . . . . . . . . . . . . . . . . 22
   15. Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
     16.1. CoAP Option Number . . . . . . . . . . . . . . . . . . . . 24
     16.2. URI Scheme Registration  . . . . . . . . . . . . . . . . . 25
   17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     18.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     18.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Changelog . . . . . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28








Becker, et al.           Expires August 9, 2013                 [Page 3]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


1.  Introduction

   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.

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 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.

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

   In 3GPP, SMS is identified as the transport protocol for small data
   transmissions (See [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
   [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.

   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.

   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.

   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.



Becker, et al.           Expires August 9, 2013                 [Page 4]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   Without store-and-forward mechanisms the delivery is absolutely
   deterministic.  There is only "success" or "failure" and no "wait a
   minute".


2.  Terminology

   The terms CoAP Server and CoAP Client are used synonymously to Server
   and Client as specified in the terminology section of
   [I-D.ietf-core-coap].


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].


4.  Scenarios

   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.

4.1.  MO-MT Scenarios

   Figure 1 to Figure 5 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 Figure 1).

                        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)

   Two mobile cellular terminals communicate by exchanging the CoAP
   Request in a short message PDU and the CoAP Response using GPRS
   transport. (depicted in Figure 2).



Becker, et al.           Expires August 9, 2013                 [Page 5]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


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

      Figure 2: Cellular and Cellular Communication (SMS/GPRS-based)

   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.

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 3).

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

         Figure 3: IP and Cellular Communication (only SMS-based)

   Again, the return path for the CoAP Response might be GPRS (depicted
   in Figure 4).








Becker, et al.           Expires August 9, 2013                 [Page 6]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


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

       Figure 4: IP and Cellular Communication (SMS and GPRS-based)

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

             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)

    Figure 5: IP and Cellular Communication (only SMS/USSD-based, using
                       an SMS/USSD 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 6).  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 6: Cellular and IP Communication (only SMS-based)



Becker, et al.           Expires August 9, 2013                 [Page 7]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


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

              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)

    Figure 7: IP and Cellular Communication (only SMS/USSD-based, using
                       an SMS/USSD service provider)

   If IP connectivity can be setup by the mobile cellular device, the
   complete communication can be handled using UDP/IP by employing
   regular CoAP [I-D.ietf-core-coap] (depicted in Figure 8.

              +------+  CoAP-REQ +-------+            +------+
              |  A   | --------> | GGSN  | ---------> |  B   |
              |(cell)| <-------- |       | <--------- | (IP) |
              +------+  CoAP-RES +-------+            +------+

           Figure 8: Cellular and IP Communication (GPRS-based)


5.  Examples

   Two mobile cellular terminals communicate by exchanging the CoAP
   Request in an SMS PDU and the CoAP Response using GPRS transport.
   (depicted in Figure 9).


                                      CoAP-REQ
                       +-----------+    (SMS)     +----------+
                       |  Client   | -----------> |  Server  |
                       |  (cell)   | <----------- |  (cell)  |
                       +-----------+   CoAP-RES   +----------+
                                        (GPRS)


                                 Figure 9

   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:



Becker, et al.           Expires August 9, 2013                 [Page 8]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   addresses in the examples are to be interpreted as described in RFC
   3966 [RFC3966].


                 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


                                 Figure 10



   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"
   |   |    |   |


                          Figure 11: NON A, NON B




















Becker, et al.           Expires August 9, 2013                 [Page 9]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   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"
   |   |    |   |


                 Figure 12: CON A, ACK A, NON B (separate)



   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"
   |   |    |   |


                 Figure 13: CON A, ACK B, NON B (separate)












Becker, et al.           Expires August 9, 2013                [Page 10]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   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"
   |   |    |   |


                          Figure 14: CON A, ACK A



   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"
   |   |    |   |


                          Figure 15: CON A, ACK B
















Becker, et al.           Expires August 9, 2013                [Page 11]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   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)
   |   |    |   |


                      Figure 16: NON A, CON B, ACK B



   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)
   |   |    |   |


             Figure 17: CON A, ACK A, CON B, ACK B (separate)










Becker, et al.           Expires August 9, 2013                [Page 12]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   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)
   |   |    |   |


             Figure 18: CON A, ACK B, CON B, ACK B (separate)


6.  Message Exchanges

6.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 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:

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

                     Figure 19: 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:



Becker, et al.           Expires August 9, 2013                [Page 13]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   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 [3gpp_ts_23_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
   [3gpp_ts_23_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.

   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.2.  Message Exchange for USSD

   The message exchange for USSD is shown simplified in Figure 20 and
   Figure 21.  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.

   Message Sequence Charts with more details can be found in
   [3gpp_ts23_090].

   In Figure 20 the message sequence chart for the USSD transport
   (Mobile Originated) is shown.













Becker, et al.           Expires August 9, 2013                [Page 14]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


           MS/CoAP CLIENT   MSC/VLR/HLR/USSD-GW         CoAP SERVER
               |                    |                        |
               | ---USSD_REQUEST--> |                        |
               |                    |                        |
               |                    | ---USSD_REQUEST_RPC--> |
               |                    | <--USSD_RESPONSE_RPC-- |
               |                    |                        |
               | <--USSD_RESPONSE-- |                        |
               |                    |                        |

          Figure 20: CoAP Messages over USSD (Mobile Originated)

   In Figure 21 the message sequence chart for the USSD transport
   (Mobile Terminated) is shown.

           MS/CoAP SERVER   MSC/VLR/HLR/USSD-GW         CoAP CLIENT
               |                    |                        |
               |                    | <--USSD_REQUEST_RPC--- |
               |                    |                        |
               | <--USSD_REQUEST--- |                        |
               | ---USSD_RESPONSE-> |                        |
               |                    |                        |
               |                    | ---USSD_RESPONSE_RPC-> |
               |                    |                        |

          Figure 21: CoAP Messages over USSD (Mobile Terminated)


7.  Encoding of CoAP for non-IP transports

7.1.  Encoding of CoAP for SMS transport

   The content of a short message can be coded in 7, 8 or 16 bit
   characters [3gpp_ts23_038].  The advantages and disadvantages are:

   a.  7 bit encoding: Sending 7 bit encoded short message possible with
       almost all devices.  CoAP binary data needs to be re-encoded,
       possibly with Base64 RFC 4648 [RFC4648].

   b.  8 bit encoding: CoAP binary data does not need to be re-encoded.
       Not all telematic devices support 8 bit short message encoding.

   c.  16 bit encoding: CoAP binary data needs to be re-encoded.  Not
       all telematic devices support 16 bit short message encoding.

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




Becker, et al.           Expires August 9, 2013                [Page 15]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


7.2.  Encoding of CoAP for USSD transport

   The encoding of USSD data is identical to the encoding of short
   messages.


8.  Message Size Implementation Considerations

   Using 7 bit encoding 160 characters are allowed in 1 short message,
   while using 8 bit encoding 140 characters are allowed.
   [3gpp_ts23_038]

   Possible options for larger CoAP messages are:

   a.  Multiple short message concatenation

   b.  CoAP Block [I-D.ietf-core-block]

   It is RECOMMENDED that SMS is not used to transfer very large
   resource data using Blocks.

   There is no possibility to concatenate messages with USSD, thus the
   only option would be CoAP Block is necessary.


9.  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.

   For mobile-originated USSD the addressing is done by a so called
   application numbers.


10.  Options

   Uri-Host: Contrary to the default value of the Uri-Host Option being
   the IP literal as given in [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 [I-D.ietf-core-coap]

   Uri-Port: The default value of the Uri-Port is not useful in
   combination with the coap+tel:// scheme.  Therefore Uri-Port MUST NOT



Becker, et al.           Expires August 9, 2013                [Page 16]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   be included, if the Uri-Host is the default value or is not included
   in the message.

   End-points receiving CoAP messages over SMS with such options MUST
   behave as specified in [I-D.ietf-core-coap].

10.1.  New Options for mixed IP/non-IP operation.

   When CoAP should be used in mixed IP and non-IP mode (e.g.  SMS/USSD
   and GPRS as in Figure 2 and Figure 4) 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.

   +----+---+---+---+---+-------------------+-------+--------+---------+
   | No | C | U | N | R |        Name       | Forma | Length | Default |
   | .  |   |   |   |   |                   | t     |        |         |
   +----+---+---+---+---+-------------------+-------+--------+---------+
   | 34 |   |   |   |   | Response-To-Uri-H | strin |  1-270 |  (none) |
   |    |   |   |   |   | o        st       | g     |    B   |         |
   | 38 |   |   |   |   | Response-To-Uri-P |  uint |  0-2 B |   5683  |
   |    |   |   |   |   | o        rt       |       |        |         |
   +----+---+---+---+---+-------------------+-------+--------+---------+

                     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.


11.  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/USSD.  The URI scheme for CoAP over SMS/USSD is
   derived from the CoAP scheme in [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 [RFC3966].

11.1.  URI Scheme

   The syntax of the "coap+tel" URI scheme is specified below in
   Augmented Backus-Naur Form (ABNF) [RFC5234].  The definitions of



Becker, et al.           Expires August 9, 2013                [Page 17]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   "path-abempty", "query", are adopted from [RFC3986].  The definition
   of "telephone-subscriber" is adopted from [RFC3966].

11.1.1.  Formal Definition

           coap-sms-URI = "coap+tel:" "//" telephone-subscriber
                          path-abempty [ "?" query ]

   telephone-subscriber = <defined in RFC3966">"
   path-abempty         = <defined in RFC3986">"
   query                = <defined in RFC3986">"

11.1.2.  Example

                 coap+tel://+15105550101/.well-known/core


12.  Transmission Parameters

   It is RECOMMENDED to configure the RESPONSE_TIMEOUT variable for a
   higher duration than specified in [I-D.ietf-core-coap] for the
   applications described here.  The actual value SHOULD be chosen based
   on experience with SMS, USSD and GPRS.


13.  Multicast

   Multicast is not possible with SMS and USSD transports.


14.  Proxying Considerations

   In case of non-IP transport, several use cases might arise for
   proxies:

   o  For a CoAP IP Client and a Mobile Terminated CoAP Server: An HTTP-
      CoAP Proxy at the mobile network / IP network border.

   o  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.

   o  If an LLN is attached to the Mobile: A CoAP-CoAP Proxy into the
      LLN.

   In Figure 22 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



Becker, et al.           Expires August 9, 2013                [Page 18]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   a constrained network is attached to the telematic device.

       +---+   *-----*   +---+   *--------*   +---+   *-----------*
       |   |  /  IP   \  |   |  / cellular \  |   |  / constrained \
       | U |-| network |-| M |-|  network   |-| T |-|    network    |
       |   |  \       /  |   |  \          /  |   |  \             /
       +---+   *-----*   +---+   *--------*   +---+   *-----------*

                        Figure 22: M2M architecture

   In sections Section 14.1 to Section 14.4 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.

14.1.  Mobile Telematic Server

             C-C: CoAP Client
             C-S: CoAP Server

       +---+   *-----*   +---+   *--------*   +---+   *-----------*
       |   |  /  IP   \  |   |  / cellular \  |   |  / constrained \
       | U |-| network |-| M |-|  network   |-| T |-|    network    |
       |   |  \       /  |   |  \          /  |   |  \             /
       +---+   *-----*   +---+   *--------*   +---+   *-----------*
         |                                      |
        C-C                                    C-S

          Figure 23: M2M architecture (Mobile Telematic Server) A


             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

          Figure 24: M2M architecture (Mobile Telematic Server) B








Becker, et al.           Expires August 9, 2013                [Page 19]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


             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

          Figure 25: M2M architecture (Mobile Telematic Server) C

14.2.  Mobile Telematic Client

             C-C: CoAP Client
             C-S: CoAP Server

       +---+   *-----*   +---+   *--------*   +---+   *-----------*
       |   |  /  IP   \  |   |  / cellular \  |   |  / constrained \
       | U |-| network |-| M |-|  network   |-| T |-|    network    |
       |   |  \       /  |   |  \          /  |   |  \             /
       +---+   *-----*   +---+   *--------*   +---+   *-----------*
         |                                      |
        C-S                                    C-C

          Figure 26: M2M architecture (Mobile Telematic Client) A


             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

          Figure 27: M2M architecture (Mobile Telematic Client) B








Becker, et al.           Expires August 9, 2013                [Page 20]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


             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

          Figure 28: M2M architecture (Mobile Telematic Client) C

14.3.  Mobile Server

             C-C: CoAP Client
             C-S: CoAP Server

       +---+   *-----*   +---+   *--------*   +---+   *-----------*
       |   |  /  IP   \  |   |  / cellular \  |   |  / constrained \
       | U |-| network |-| M |-|  network   |-| T |-|    network    |
       |   |  \       /  |   |  \          /  |   |  \             /
       +---+   *-----*   +---+   *--------*   +---+   *-----------*
         |                                                  |
        C-C                                                C-S

               Figure 29: M2M architecture (Mobile Server) A


             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

               Figure 30: M2M architecture (Mobile Server) B








Becker, et al.           Expires August 9, 2013                [Page 21]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


             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

               Figure 31: M2M architecture (Mobile Server) C


             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

               Figure 32: M2M architecture (Mobile Server) D

14.4.  Mobile Client

             C-C: CoAP Client
             C-S: CoAP Server

       +---+   *-----*   +---+   *--------*   +---+   *-----------*
       |   |  /  IP   \  |   |  / cellular \  |   |  / constrained \
       | U |-| network |-| M |-|  network   |-| T |-|    network    |
       |   |  \       /  |   |  \          /  |   |  \             /
       +---+   *-----*   +---+   *--------*   +---+   *-----------*
         |                                                  |
        C-S                                                C-C

               Figure 33: M2M architecture (Mobile Client) A







Becker, et al.           Expires August 9, 2013                [Page 22]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


             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

               Figure 34: M2M architecture (Mobile Client) B


             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

               Figure 35: M2M architecture (Mobile Client) C


             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

               Figure 36: M2M architecture (Mobile Client) D






Becker, et al.           Expires August 9, 2013                [Page 23]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


15.  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.

   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.

   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.

   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
   [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.


16.  IANA Considerations

16.1.  CoAP Option Number

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

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




Becker, et al.           Expires August 9, 2013                [Page 24]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


16.2.  URI Scheme Registration

   This document requests the registration of the Uniform Resource
   Identifier (URI) scheme "coap+tel".  The registration request
   complies with [RFC4395].

   URI scheme name.

   coap+tel

   Status.

   Permanent.

   URI scheme syntax.

   Defined in Section 11 of [RFCXXXX].

   URI scheme semantics.

   TBD

   Encoding considerations.

   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.

   Applications/protocols that use this URI scheme name.

   The scheme is used by CoAP endpoints to access CoAP resources over
   non-IP transports, i.e. cellular networks.

   Interoperability considerations.

   None.

   Security considerations.

   See Section 15 of [RFCXXXX].

   Contact.

   IETF Chair <chair@ietf.org>

   Author/Change controller.

   IESG <iesg@ietf.org>



Becker, et al.           Expires August 9, 2013                [Page 25]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


   References.

   [RFCXXXX]


17.  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.


18.  References

18.1.  Normative References

   [3gpp_ts23_038]
              ETSI 3GPP, "Technical Specification: Alphabets and
              language-specific information (3GPP TS 23.038 version
              10.0.0 Release 10)", 2011.

   [3gpp_ts23_090]
              ETSI 3GPP, "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)", 2011.

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

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

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-13 (work in progress), December 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate



Becker, et al.           Expires August 9, 2013                [Page 26]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


              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.

18.2.  Informative References

   [3gpp_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.

   [3gpp_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.

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

   [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.

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






Becker, et al.           Expires August 9, 2013                [Page 27]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


Appendix A.  Changelog

   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.  Table 1

   Changed from draft-01 to draft-02:

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

   o  Reply-To-* changed to Response-To-*.  Section 16 and Section 10.1

   o  Added URI scheme.  Section 11

   o  Added possible CON/NON/ACK interactions.  Section 5

   o  Added possible M2M proxy scenarios.  Section 14

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

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

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

   o  Added an IANA registration for the URI scheme.  Section 16.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






Becker, et al.           Expires August 9, 2013                [Page 28]


Internet-Draft             CoAP SMS/USSD/GPRS              February 2013


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

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


   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 August 9, 2013                [Page 29]


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