Kurt Roots

May 8, 2008
University of St. Thomas
SEIS 645
Project 3 and 4

Short Message Service (SMS)

Protocols and Architecture

1
 The Short Message Service, also known as SMS, is a nascent technology
especially for the United States. It was reported that in the second quarter of
2007, the wireless company Verizon alone coordinated the exchange of 28.4
billion text messages. This is a dramatic increase over the reported 14.4 million
total text messages sent per month in 2000. [3]

Since the first commercial text message was sent in 1992 [3], the
protocols, architectures, and even governing bodies have evolved to define what
is considered today’s current standard. As organizations look to leverage this
technology in response to increasing customer demand, it is imperative to have a
thorough understanding of the current specifications outlined for the
comprehensive technology considered SMS.

The protocols associated with SMS have evolved since the first
commercial text message was sent in 1992. Today the 3rd Generation
Partnership Project (3GPP) maintains the SMS standard. [3] In addition to
officially recognizing SMS as a communication protocol, they also recognize five
main short message service center (SMSC, SC or SMS-C) access protocols,
though only four are primarily used. These mainstream protocols, which include
SMPP, CIMD, UCP/EMI, and OIS, are proprietary binary access protocols
associated with SMS that communicate over TCP/IP or X.25. [2, p. 114]

Although the 3GPP is the prominent governing body with the most widely
used standards and strategic partnerships, there are others. The 3rd Generation
Partnership Project 2 (3GPP2) focuses on another 3G (third generation)
technology. [8] While the 3GPP describes standards for communication over the
Global System for Mobile Communications (GSM) [4], the specifications outlined
by the 3GPP2 focus strictly on digital communication through code division
multiple access (CDMA). [9] Companies like Sprint and Verizon use this digital
technology in the U.S. while GSM has much wider adoption that spans the globe.
[5, p. 3] These competing standards highlight the extensive spectrum of protocols
available within systems but also the accompanying confusion that underlies
SMS standards.

The GSM platform specifies standards and approaches utilized by roughly

85 countries worldwide. [4] The technical realization specification as outlined by
the 3GPP details in great length the service elements, service and message
center functionality, routing, architecture, and protocols used within the SMS
standard for GSM systems. The 3GPP also produces other specification
documents for things like requirements, security, data, and program
management, all relating to SMS. It is important to note that this main
specification document focuses on the communication between mobile stations
(MS or mobile user) and SCs. [1, p. 15] SMS communication can really extend
beyond just the SC to entities like the aggregator or broker (and with other
protocols like CDMA). In this type of architecture, which will be discussed later,

2
an aggregator interfaces to a service or application provider to sends or receives
short messages. [5, p. 4]

Between the MS and the SC there are two basic functions or services that
can occur. This first service, the Short Message Mobile Terminated (SM MT),
enables the SC to send a message to one MS with the understanding that a
delivery or error report will be sent back to the SC. If there is an error report, it is
expected that there will be a mechanism for later delivery. The second service,
which is called Short Message Mobile Originated (SM MO), enables the
GSM/UMTS system to send one message from a MS to a short message entity
(SME) through an SC. Along with the short message, it is expected that a
delivery or error report will be included as part of the communication, similar to
the SM MT service. [1, p. 15]

The MS and SC components involved with these services have

expectations associated with their role in facilitating communication. The MS is
expected to be able to submit and receive short message transfer protocol data
units (TPDUs) at any time, regardless if there is data or voice activity present. In
the case where the MS is receiving the short message, a detailed report should
always be sent to the SC indicating a success or failure. Likewise, when the MS
is submitting a message, a report should be returned to the MS, either indicating
that the message to the SC was received or that an error occurred. If there was
an error, details of the problem should be included in the report. [1, p. 16]

These two fundamental communication services are supported through

eight different elements that define a set of rules for submitting and receiving
messages. The elements as defined by the 3GPP specification include validity
period, service center time stamp, protocol identifier, more messages to send,
priority, messages waiting, alert SC, and MT correlation ID. The various rules are
essential to the communication that is available in the two basic services of SMS.
[1, p. 16]

Extending beyond the services and elements of SMS, the foundation for
communication in these services is carried out through specific protocols. The
protocol stack, as outlined in Figure 2 in Appendix B, represents four different
layers: the Short Message Lower Layer (SM-LL), the Short Message Relay Layer
(SM-RL), the Short Message Transfer Layer (SM-TL), and the last layer, the
Short Message Application Layer (SM-AL). The bulk of the functionality of SMS
occurs in the relay and transfer layers which are outlined extensively in the
technical specification from 3GPP. [1, p. 43] The application layer is tightly
coupled with protocols like SMPP that operate broadly with protocols outside the
SMS protocol stack. [6, p. 25]

The SM-RL, which is built on top of the lower layer, provides service to
SM-TL. It is comprised of six protocols, which collectively allow the SM-TL to
send and receive TPDUs between its peer nodes. It also provides the SM-TL

3
layer the ability to report information regarding previously occurring TPDU
transfers. This communication between layers is possible through a Short
Message Identifier (SMI), which is actually a reference number for the TPDU that
is carried in the relay layer. [1, p. 107]

The six protocols that comprise the relay layer are used for different
functions, depending on the action and entity referenced in the layer. The table
below (Table 1) highlights these protocols and their basic purpose.

Relay Layer Protocol Name Protocol Purpose

RP-MO-DATA Transfer a TPDU from MS to SC.
RP-MT-DATA Transfer a TPDU from SC to MS.
RP-ACK Acknowledge an RP-MO-DATA or an
RP-MT-DATA
RP-ERROR Report a failure RP-MO-DATA or an
RP-MT-DATA transfer attempt.
RP-ALERT-SC Alerting the SC that the MS has recovered an
operation.
RP-SM-MEMORY-AVAILABLE Notify the network that the MS has memory
available to accept one or more messages.
Table 1. Relay Layer Protocols (Source: 3GPP TS 23.040, p. 107)

The RP-MO-DATA protocol is responsible for transferring a short

message TPDU from a MS to a SC. This protocol contains specific abbreviations
and references for carrying out the intended functionality. These components,
which are essentially the granular elements or attributes of the protocol, consist
of the originating address, the destination address, and the short message data
(user data). [1, p. 108]

The RP-MT-DATA protocol allows communication between a SC and the

MS. Like the RP-MO-DATA protocol, there are additional components that define
the operational behavior of the protocol. Unlike the RP-MO-DATA protocol
however, there is more functionality provided in this protocol. In addition to
capturing the originating address, destination address, and the user data, the
RP-MT-DATA protocol can handle issues with priority requests, additional
messages, message types, and originating SME addresses. [1, p. 108]

The priority request parameter of RP-MT-DATA, which is required from an

SC, indicates whether or not to stop the transfer if the originating SCs address is
already available. If the address is available, it is found in the
Messages-Waiting-Data (MWD), which is indicated by the
Messages-Waiting-Indication (MWI). The MWD and MWI are structures used by
SCs as control mechanism for handling messages that need to be resent. This
request parameter helps utilize the use of these facilities. [1, p. 108]

The More-Messages-To-Send parameter, which is optional, indicates that

more messages are waiting to be processed by the service center. The
Message-Type-Indicator parameter can indicate whether message delivery was

4
successful or there was an error. By allowing the parameterization of protocols,
specifically by the RP-MT-DATA protocol, message passing between the SC and
MS can be feature-rich and flexible. [1, p. 108]

The RP-ACK, the RP-ERROR, and the RP-ALERT-SC protocols are

straightforward in their purposes. Like the two previous high-level protocols in the
relay layer, the RP-ACK uses the RP-User-Data parameter that contains the
actual short message. This protocol is used for acknowledgement in
RP-MO-DATA or RP-MO-DATA transfers. The RP-ERROR protocol also packs
the short message into the RP-User-Data parameter (optionally used, however),
which it uses for error handling. Additionally, it contains other parameters
specifically related to handling errors. These include tracking the cause of the
error and checking the MWI status. [1, p. 108-109]

The RP-ALERT-SC, which is mandatory on all nodes, contains only one

parameter, which is used to store the Mobile Subscriber Integrated Services
Digital Network Number (MSISDN) of the MS. The protocol
RP-SM-MEMORY-AVAILABLE optionally stores the
International-Mobile-Subscriber-Identity (IMSI) of the MS. [1, p. 109] These
protocols that manage this capability are vital because MSISDN and IMSI
identifiers are key communication components of GSM. [4]

Moving upwards from the relay layer is the transfer and application layer.
The SM-TL of the protocol stack interacts with the SM-AL through communicative
actions. By acting as an enabler, the transfer layer allows the application layer to
interface with other nodes or entities by facilitating both the sending and
receiving of messages or reports. As in the interface between the SM-RL and the
SM-TL, the transfer layer and application layers are connected by a SMI. It
should be noted that the SMIs are unique between layers, so it is unlikely that the
same SMI will be used between the SM-RL and SM-TL that is used between the
SM-TL and the SM-AL. [1, p. 48]

The transport layer relies on several protocol data unit (PDU) types to
carry out its required responsibilities. [1, p. 48] These types are based on the
protocol description unit (PDU) method, which is one of two ways to send and
receive messages over GSM systems. The other supported method, which is
called text mode, is the most primitive method that is not supported on every
phone. [7] Thus the SM-TL relies on PDU mode rather than text mode.

In Table 2 below, the six PDUs utilized by the transfer layer are briefly
described. Similar to the protocols and associated parameters found in the relay
layer, each PDU is a transport format used for a specific purpose. Each contains
mandatory or optional parameters that enable this functionality.

Transfer Layer Protocols Protocol Purpose

SMS-DELIVER Represents a short message from the SC to
the MS.

5
SMS-DELIVER-REPORT Represents an error or info as part of a positive
or negative acknowledgement to SMS-
DELIVER or SMS-STATUS-REPORT.
SMS-SUBMIT Represents a short message from the MS to
the SC.
SMS-SUBMIT-REPORT Represents an error or info as part of a positive
or negative acknowledgement to SMS-SUBMIT
or SMS-COMMAND.
SMS-STATUS-REPORT Represents a status report from the SC to the
MS.
SMS-COMMAND Represents a command from the MS to the
SC.
Table 2. Transfer Layer PDU Types (Source: 3GPP TS 23.040, p. 48)

The SMS-DELIVER protocol contains the standard for transporting a short

message from the SC to the MS. It utilizes several parameters, most of which are
mandatory. Like the other PDUs, the data and information contained in this PDU
can be represented as integers, one bit, two bits, octets (o), 7 octets (7o), or
2-12 octets (2-12o). [1, p. 49] In Table 3 below, an SMS-DELIVER messages has
been implemented with actual information using a sample TPDU.

Transfer protocol data unit:

07917283010010F5040BC87238880900F10000993092516195800AE8329BFD4697D9EC37

Octet(s) Description
07 Length of the SMSC information (in this case, 7 octets).
91 Type-of-address of the SMSC (91 means international format of the
phone number).
72 83 01 00 10 F5 Service center number (in decimal semi-octets). The length of the
phone number is odd (11), so a trailing F has been added to form
proper octets. The phone number of this service center is
“+27381000015.”
04 First octet of this SMS-DELIVER message.
0B Address length. Length of the sender number (0B hexadecimal = 11
decimal).
C8 Type-of-address of the sender number.
72 38 88 09 00 F1 Sender number (decimal semi-octets), with a trailing F
(“+27838890001”).
00 Protocol identifier (00 = SME-to-SME protocol—implicit).
00 Data coding field (00 = 7 bit, 01 = 8 bit, 10 = 16 bit, 11 = reserved).
99 30 92 51 61 95 80 Time stamp (semi-octets) in order (YY, MM, DD, HH, MM, SS,
TIMEZONE in relation to GMT in units of 15 minutes). So,
0x99 0x30 0x92 0x51 0x61 0x95 0x80 means 29 Mar 1999 15:16:59
GMT+2.
0A User data length: length of message. The data-coding field indicated
7-bit data, so the length here is the number of septets (10). If the data-
coding field were set to indicate 8-bit data or Unicode, the length
would be the number of octets (9).
E8329BFD4697D9EC37 Message “hellohello,” 8-bit octets representing 7-bit data.
Table 3. SMS-DELIVER Message (Source: SMS: The Short Message Service)

The determination of how the information is represented is based on the

type of the parameter for the particular PDU, but it also is a reflection of the

6
payload capabilties and how data is packaged in GSM. The SMSC can send
ascii or binary data with maximum payloads of 140 octets to the MS, which
indicates that the upper bound of message length is 160 characters when using
7-bit encoding. [3] Other encoding schemes, such as 8-bit or 16-bit, can also be
specified but they reduce the message length significantly. An 8-bit encoding
scheme, which is typically used for smart messages like images and ring tones,
reduces message length to a maximum of 140 characters. When 16-bit encoding
is used for unicode text messages, the character length is further reduced to a
maximum of 70 characters. [7]

An SMS-DELIVER-REPORT PDU type also contains mandatory and

optional parameters that collectively define the type and overall message. This
message could be carried within an RP-ERROR element as a negative
acknowledgement to an SMS-DELIVER or an SMS-STATUS-REPORT. It could
also be a message found within an RP-ACK element that provides positive
affirmation to an SMS-DELIVER or an SMS-STATUS-REPORT. The difference
between these two cases is technical. The message carried in the event of an
error contains an extra parameter that indicates the reason for the SMS-
DELIVER failure. [1, p. 51]

The SMS-SUBMIT protocol is a very self-descriptive protocol unit that

contains the short message sent from the MS to an SC. As a complementary
protocol, the SMS-SUBMIT-REPORT PDU type is carried out through an
RP-User-Data element within an RP-ERROR or an RP-ACK PDU. This provides
for a negative acknowledgement or a positive acknowledgement to the SMS-
SUBMIT, depending on the context of the transmission. As in the SMS-
DELIVER-REPORT PDU, the message containing the negative
acknowledgement provides room in the specification to allow for additional
information regarding the reason for the failure. [1, p. 55]

The SMS-STATUS-REPORT provides the receiving MS with status

information regarding a previously submitted short message by the MS. This
status information might indicate whether or not that the SC was able to forward
the message or whether the SC is storing the message for later delivery. The
SMS-STATUS-REPORT can be invoked from several sources, including the
SMS-COMMAND. [1, p.57] The SMS-COMMAND has the capability of enabling
an MS to issue commands that operate at the SC. For example, an MS might
request an SC to delete, cancel an SMS-STATUS-REPORT, or even request the
status of a message. [1, p. 14]

These six protocols constitute the vitally important transfer layer.

Interfaced with the application and relay layer yet accessible to the lower layer
through the relay connections, this four-layer protocol stack is the foundation to
enabling short message communication between the MS and the SC. This
specification however does not fully describe the protocols or implementation

7
used during the interaction between two SCs or an outside SME and an SC. [2,
p. 114]

The primary protocol for communication between two SCs is SMPP.

Version 5.0 is the latest version of the Short Message Peer to Peer (SMPP)
protocol which is managed by the SMS Forum. Initially developed by Logica (now
known as LogicaCMG) [2, p 114], SMPP is an open and industry standard
access protocol [6, p. 16] that facilitates the communication between SCs or
between external short message entities (ESMEs) and SCs. ESMEs are typically
software applications or network devices that can send and receive short
messages. [3] In an architecture where content providers are used, SMPP is
used to maintain connections between the SC and the message broker. [3] In
Figure 3 from Appendix B, these connections that show SMPP relative to an
overall SMS architecture is featured. The SMPP protocol in this network diagram
not only connects SCs and ESMEs, but it also connects routing entities (RE) with
each other and REs to SCs. [6, p. 12]

The SMPP protocol is quite flexible and supports both GSM/UMTS and
CDMA systems. System independent, the protocol is reliant on sessions that
operate over TCP/IP or X.25 like the other mainstream protocols utilized within
SMS. Each session is established between two entities, such as between an
ESME and a SC, and can establish one of three different session types. The
transmitter (TX) sessions are essentially SM MT message types while receiver
(RX) sessions are SM MO. The transceiver session (TRX) is a combination of
both SM MO and SM MT and allows for a single SMPP session to submit mobile
terminated messages and receive mobile originated messages. The sessions
used in the SMPP protocol build on the foundations outlined in the basic SMS
services. [6, p. 20]

The SMPP protocol must operate through TCP/IP or X.25 because it is an

application layer protocol (X.25, studied in class, is part of the OSI protocol suite
and it is a protocol that is used for packet switching services [10]). This means
that SMPP uses the same underlying communication protocols as HTTP,
TELNET, and FTP. These associated communication protocols complete some
of the important tasks for SMPP, including the ability to handle to corruption and
error detection. The methods of CRC and bit parity studied in class are not
supported by SMPP because the protocol relies on the other communication
protocols found in the application layer. Figure 4 in Appendix B represents the
communication between an ESME and a MC at the application layer of the OSI
model. This protocol architecture is distinct from the core protocol stack found in
SMS. [6, p. 25]

Like the protocols established for interaction between a MS and the SC,
SMPP is based on a series of PDUs that control operations for ESMEs or MCs.
Although there are several SMPP PDUs available, the general categories for
these protocols are outlined in Table 4 below. [6, p. 21]

8
SMPP PDU Category Description
Session Management Operations are designed to enable the
establishment of SMPP sessions between an
ESME and MC and provide means of handling
unexpected errors.
Message Submission These operations are designed specifically for
the submission of messages from ESME(s) to
the MC.
Message Delivery These operations enable a MC to deliver
messages to the ESME.
Message Broadcast These operations are designed to provide Cell
Broadcast service within a Message Center.
Ancillary Operations These operations are designed to provide
enhanced features such as cancellation, query
or replacement of messages.
Table 4. SMPP PDU Types (Source: SMS Forum, SMPP V5.0 Specification)

Figure 1 from Appendix B also depicts the use of SMPP where the service
provider accesses the broker by using the SMPP protocol. Although both Figure
1 and 2 outline SMPP as the key communication protocol between SCs and
ESMEs and it is the most widely supported protocol for this purpose, message
brokers can use custom APIs written in Java or PHP to make this connection. [3]

This content provider architecture describes a situation where someone is

looking to publish content to users. According to the Computer magazine article
“SMS: The Short Message Service”, a mobile content provider publishes value-
added content to mobile users. In reality, anyone can publish content, which may
or may not be value-added. The book How to Build an SMS Service was written
to bring SMS content to the masses by providing an explanation of the SMS
architecture required to publish mobile content. Regardless of the quality of the
content though, SMS has effective messaging capabilities just like e-mail. [5, p.
13]

When a mobile user sends a text message to another user, the phone
sends the message to a cell tower, which is then passed to a SC. There the
message is stored and delivered when the recipient becomes available on the
network. This SMS architecture is highlighted in Figure 1 from Appendix B. [3]
The delivery mechanism used here is very similar to e-mail, which is also
considered a store-and-forward system. (SMS also supports a forward-and-forget
mechanism) The SC will hold the messages from 24 to 48 hours, [5, p 13]
however this time limit is usually configurable. Similar to e-mail, the delivery
period during this time can be periodic and somewhat limited. [3] The delivery
could even fail, but as indicated by the SMS protocol, delivery and failure
situations are features required by the communication mechanism.

The short message service is a comprehensive system for communicating

information over mobile devices. The overall architecture is fairly straight-forward,
but anyone looking to implement a SMS system should be aware of the

9
differences between governing bodies like 3GPP and the 3GPP2 and the
fundamental differences in the technologies that they support. GSM and CDMA
systems support different protocol stacks that would influence the SMS
architecture.

This paper defined the key protocols and how they are used within the
SMS architecture as defined by 3GPP. These protocols, which facilitate
communication between mobile users and service centers, are built on top of
GSM systems, which have the most support globally. While technical in nature,
each protocol of the stack is designed to carry out a specific function within SMS.
Additional protocols outside the formal technical specification of SMS define the
relationship between service centers and message aggregators. The most
prominent of these is SMPP, which enables the communication between service
centers and external message entities at that highest layer of the OSI model.
This application level protocol provides a broad interface for the SMS
components and is governed by a separate body known as the SMS Forum.

As the use of SMS continues to rise globally, the protocols and

architectures will continue to evolve and in some cases compete. Clear
language, simplification of redundant terminology, and consolidation into global
standards would greatly benefit SMS. Like other areas of telecommunications
and fields in the general tech industry, these formidable challenges of SMS will
likely remain for quite some time. Therefore, understanding the aforementioned
protocols and architectures are imperative to comprehending SMS.

10
Appendix A

References

[1] 3GPP Technical Specifications, 23.040. 2008. Online. Internet. 04/15/2008.

< http://www.3gpp.org/ftp/Specs/html-info/23040.htm >.

[2] Bodic, Gwenaël Le. (2005). Mobile Messaging Technologies and Services:
SMS, EMS and MMS. Buckingham: John Wiley and Sons.

[3] Brown, Jeff; Shipman, Bill; Vetter, Ron, SMS: The Short Message Service,
Computer, Volume 40, Issue 12, Dec. 2007, pp. 106.

[4] Introduction to GSM. 2008. Online. Internet. 04/26/2008.

< http://www.pt.com/products/gsmintro.html >.

[5] Schwartz, Jordan; Retford, Brian. (2007). How to Build an SMS Service.
O’Reilly Media.

[6] SMS Forum, SMPP V5.0 Specification. 1999-2007. Online. Internet.

04/12/2008.
< http://www.smsforum.net/ >.

[7] SMS messages and the PDU format. Online. Internet. 04/26/2008.
< http://www.dreamfabric.com/sms/ >.

[8] Wikipedia – 3GPP. 2008. Online. Internet. 04/28/2008.

< http://en.wikipedia.org/wiki/3GPP >.

[9] Wikipedia - Code division multiple access. 2008. Online. Internet. 04/13/2008.
< http://en.wikipedia.org/wiki/Code_division_multiple_access >.

[10] Wikipedia - X.25. 2008. Online. Internet. 04/27/2008.

< http://en.wikipedia.org/wiki/Code_division_multiple_access >.

11
Appendix B

Figure 1. SMS Architecture (Source: 3GPP Technical Specifications)

Figure 2. SMS Protocol Stack (Source: 3GPP Technical Specifications)

12
Figure 3. SMPP in SMS Architecture (Source: SMS Forum, SMPP V5.0 Specification)

Figure 4. Application Layer - ESME and MC (Source: SMS Forum, SMPP V5.0 Specification)

13