Transport of CoAP over SMS, USSD and GPRS
draft-becker-core-coap-sms-gprs-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Markus Becker , Kepeng Li , Koojana Kuladinithi , Thomas Poetsch | ||
| Last updated | 2012-03-01 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-becker-core-coap-sms-gprs-01
CoRE Working Group M. Becker, Ed.
Internet-Draft ComNets, TZI, University Bremen
Intended status: Informational K. Li
Expires: September 2, 2012 Huawei Technologies
K. Kuladinithi
T. Poetsch
ComNets, TZI, University Bremen
March 1, 2012
Transport of CoAP over SMS, USSD and GPRS
draft-becker-core-coap-sms-gprs-01
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 September 2, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Becker, et al. Expires September 2, 2012 [Page 1]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. MO-MT Scenarios . . . . . . . . . . . . . . . . . . . . . 4
4.2. MT Scenarios . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. MO Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
5. Message Exchanges . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Message Exchange for SMS in a Cellular-To-Cellular
Mobile-Originated and Mobile-Terminated Scenario . . . . . 7
5.2. Message Exchange for USSD . . . . . . . . . . . . . . . . 8
6. Encoding of CoAP for non-IP transports . . . . . . . . . . . . 9
6.1. Encoding of CoAP for SMS transport . . . . . . . . . . . . 9
6.2. Encoding of CoAP for USSD transport . . . . . . . . . . . 10
7. Message Size Implementation Considerations . . . . . . . . . . 10
8. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. New Options for mixed IP/non-IP operation. . . . . . . . . 11
10. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 11
11. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12. Proxying Considerations . . . . . . . . . . . . . . . . . . . 11
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
14. Security Considerations . . . . . . . . . . . . . . . . . . . 12
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
16.1. Normative References . . . . . . . . . . . . . . . . . . . 12
16.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Becker, et al. Expires September 2, 2012 [Page 2]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
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 GPRS, HSPA or LTE.
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.
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 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
Becker, et al. Expires September 2, 2012 [Page 3]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
"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 SMS 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 an SMS PDU and the CoAP Response using GPRS transport.
(depicted in Figure 2).
Becker, et al. Expires September 2, 2012 [Page 4]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
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 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 an SMS
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 September 2, 2012 [Page 5]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
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 an SMS, 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 September 2, 2012 [Page 6]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
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. 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 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:
MS/CoAP CLIENT Service Center MS/CoAP SERVER
| | |
| ---SMS-SUBMIT---> | |
| <-SMS-SUBMIT-REPORT-- | |
| | |
| | --SMS-DELIVER---> |
| | <-SMS-DELIVER-REPORT-- |
| | |
| <-SMS-STATUS-REPORT-- | |
| | |
Becker, et al. Expires September 2, 2012 [Page 7]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
Figure 9: 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 [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.
5.2. Message Exchange for USSD
The message exchange for USSD is shown simplified in Figure 10 and
Figure 11. 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 10 the message sequence chart for the USSD transport
(Mobile Originated) is shown.
Becker, et al. Expires September 2, 2012 [Page 8]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
MS/CoAP CLIENT MSC/VLR/HLR/USSD-GW CoAP SERVER
| | |
| ---USSD_REQUEST--> | |
| | |
| | ---USSD_REQUEST_RPC--> |
| | <--USSD_RESPONSE_RPC-- |
| | |
| <--USSD_RESPONSE-- | |
| | |
Figure 10: CoAP Messages over USSD (Mobile Originated)
In Figure 11 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 11: CoAP Messages over USSD (Mobile Terminated)
6. Encoding of CoAP for non-IP transports
6.1. Encoding of CoAP for SMS transport
The content of SMS 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 SMS 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 SMS encoding.
c. 16 bit encoding: CoAP binary data needs to be re-encoded. Not
all telematic devices support 16 bit SMS encoding.
Becker, et al. Expires September 2, 2012 [Page 9]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
6.2. Encoding of CoAP for USSD transport
The encoding of USSD data is identical to the encoding of SMS.
7. Message Size Implementation Considerations
Using 7 bit encoding 160 characters are allowed in 1 SMS, while using
8 bit encoding 140 characters are allowed. [3gpp_ts23_038]
Possible options for larger CoAP messages are:
a. Multiple SMS 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.
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 SMS 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.
9. Options
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.
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.
End-points receiving CoAP messages over SMS with such options MUST
behave as specified in [I-D.ietf-core-coap].
Becker, et al. Expires September 2, 2012 [Page 10]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
9.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 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.
OPEN QUESTION: Are CoAP user option numbers applicable here?
+--------+----------+-------------------+--------+--------+---------+
| Number | C/E | Name | Format | Length | Default |
+--------+----------+-------------------+--------+--------+---------+
| TBD | Critical | Reply-To-Uri-Host | string | 1-270 | (none) |
| | | | | B | |
| TBD | Critical | Reply-To-Uri-Port | uint | 0-2 B | 5683 |
+--------+----------+-------------------+--------+--------+---------+
Table 1: New CoAP Option Numbers
10. Protocol Constants
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.
11. Multicast
Multicast MUST NOT be used with the SMS and USSD transports.
12. 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.
Becker, et al. Expires September 2, 2012 [Page 11]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
13. IANA Considerations
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.
14. Security Considerations
Security mechanisms defined in [3gpp_ts23_888] are used to guarantee
transport security.
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.
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 and Nils Schulte for the discussion.
16. References
16.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.
Becker, et al. Expires September 2, 2012 [Page 12]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
[I-D.ietf-core-block]
Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP",
draft-ietf-core-block-08 (work in progress),
February 2012.
[I-D.ietf-core-coap]
Frank, B., Bormann, C., Hartke, K., and Z. Shelby,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-08 (work in progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
16.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.
[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 September 2, 2012 [Page 13]
Internet-Draft CoAP SMS/USSD/GPRS March 2012
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
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 September 2, 2012 [Page 14]