Abstract

This tutorial presents an overview of the Global System for Mobile Communications Short Message Service from the viewpoint of implementing
new telematic services. SMS offers the users of GSM networks the ability to exchange alphanumeric messages up to the limit of 160 characters.
The tutorial is motivated by an acute absence of research publications in this field. The information gathered in the tutorial was required
considering the increasing potential SMS offers for integration with existing messaging services and its ability to offer a successful replacement
for the Transmission Control and Internet Protocols as far as low-bandwidth-demanding applications are concerned. Initially, the tutorial gives a
brief overview of the building blocks of GSM networks — the mobile station, base station, and network subsystem — and then emphasizes the
SMS network and protocol architecture. The most widely used protocols for message submission are then introduced (text-based, SMS2000,
ETSI 0705, TAP) and compared in terms of features provided and flexibility to handle extended alphabets or two-way messaging. Finally the
tutorial outlines a summary of current and future issues for further development and research in the light of novel features for submission
protocols and telematic services.

The Global System for

Mobile Communications
Short Message Service
Guillaume Peersman and Srba Cvetkovic,
The University of Sheffield
Paul Griffiths and Hugh Spear, Dialogue Communications Ltd.

S ince the first Global System

for Mobile Communications (GSM) network started opera-
tion in 1991, more than 100 countries have adopted the stan-
dard. Over 20 million subscribers of GSM networks are now
offered worldwide coverage, outstanding voice quality over a
whole range of operating conditions, and a variety of value-
added services. These services include voice mail, call han-
dling facilities, call line identification, and Short Message
Service (SMS).
With SMS, users are able to exchange alphanumeric mes-
sages (up to 160 characters) with other users of digital cellular
networks, almost anywhere in the world, within seconds of
submission. Even if the service was originally conceived as a
paging mechanism for notifying the users of voicemail mes-
sages, SMS is now increasingly used as a messaging service.
The messages are typically created on mobile phone keypads,
which is somewhat awkward. Fortunately, there are other
ways to access the message centers, as discussed in this article.
Numerous applications are already available and make short
message reception and submission possible using a computer.
Gateway architectures are also being widely implemented and
connect company’s e-mail or voicemail systems to the SMS.
The practical implementation of SMS and the different
protocols for message submission are addressed in this article.
The future of SMS and a brief review of the fields currently
being studied will conclude this article.
The Short Message Service
Developed as part of the GSM Phase 2 specification, the
Short Message Service, or SMS as it is more commonly
known, is based on the capability of a digital cellular terminal
to send and/or receive alphanumeric messages. The short
messages can be up to 140 bytes in length, and are delivered
within a few seconds where GSM coverage is available. More
than a common paging service, the delivery of the message is
guaranteed even when the cellular terminal is unavailable
(e.g., when it is switched off or outside the coverage area).
The network will hold the message and deliver it shortly after
the cellular terminal announces its presence on the network.
The fact that SMS (through GSM) supports international
roaming with very low latency makes it particularly suitable
for applications such as paging, e-mail, and voice mail notifi-
cation, and messaging services for multiple users. However,
the facilities offered to users and the charges for these facili-
ties still mainly depend on the level of service provided by the
network operator.
There are two types of SMS available: cell broadcast [1]
and point-to-point [2]. In cell broadcast, a message is trans-
mitted to all the active handsets or mobile stations (MSs) pre-
sent in a cell that have the capability of receiving short
messages and have subscribed to this particular information
service. This service is only one-way, and no confirmation of
receipt will be sent. It can send up to 93 7-bit character or 82
8-bit characters, typically used to transmit messages about
traffic conditions, weather forecast, stock market, and so on.
In point-to-point service, messages can be sent from one
mobile to another or from a PC to a mobile and vice versa.
These messages are maintained and transmitted by an SMS
Center (SMSC). The SMSC is an electronic form of ordinary
mail postal service that stores and then forwards the messages
when they can be delivered. Each GSM network must support
one or more SMSCs to sort and route the messages. Each
SMSC checks, organizes, and sends the message to the opera-

IEEE Personal Communications • June 2000 1070-9916/00/$10.00 © 2000 IEEE 15

 Um Abis
ME
BTS
BSC
SIM
BTS
Mobile
station
Base station subsystem
Other base station subsystem
PSTN/ISDN
BTS: Base transceiver station
BSC: Base station controller
SIM: Subscriber identity module
ME: Mobile equipment
■ Figure 1. The basic GSM network architecture.
tor. It also receives and passes on any confirmation messages to
any GSM mobile on any network. However, in practice, there
are no agreements to allow SMS to travel between networks.
There are several ways in which a short message can be
submitted, depending on the interfaces supported by the GSM
network SMSC. Users can call a central paging bureau (i.e.,
an operator), or directly create the message on the keypad of
their handset. Typing the messages is made easier when using
a personal digital assistant (PDA) or a laptop connected to
the handset. A few SMSC equipment manufacturers and com-
panies have also developed their own protocols for short mes-
sage submission. Consequently, more and more GSM
networks now offer access to their SMSC using these proto-
cols over a variety of hardware interfaces: modem dialup,
X25, and even the Internet.
GSM Network Architecture
The layout of a generic GSM network with its several func-
tional entities is shown in Fig. 1 [3]. The architecture can be
divided in three main components:
• The subscriber holds the MS, namely the GSM terminal
• The base station subsystem controls the radio link with the
MS
• The network subsystem performs the switching of calls and
other management tasks such as authentication.
The Mobile Station
The MS and base station subsystem communicate across the
Um interface, also known as the air interface or radio link.
The base station subsystem communicates with the network
subsystem across the A interface. The MS consists of the
physical terminal and contains the radio transceiver, the dis-
play and digital signal processors, and the Subscriber Identity
Module (SIM). The SIM provides the user with the ability to
access their subscribed services regardless of the location and
the terminal used. The insertion of the SIM in any GSM cel-
lular phone allows the user to access a network, make and
receive phone calls, and use all the subscribed services.
The International Mobile Equipment Identity (IMEI)
uniquely identifies the mobile terminal according to the Inter-
national Mobile Subscriber Identity (IMSI) contained in the
16
A
VLR AuC EIR HLR
Operation and
MSC maintenance center
Data communication
SMSC network
Network subsystem
AuC: Authentication centre
EIR: Equipment identity register
HLR: Home location register
VLR: Visitor location register
SIM. Because the IMEI and IMSI are independent, personal
mobility is possible. The SIM can be protected against unau-
thorized use by a personal identity number (PIN).
The Base Station Subsystem
The base station subsystem is composed of two parts, the
base transceiver station (BTS) and base station controller
(BSC). They communicate across the specified Abis inter-
face, thus allowing network operators to use components
made by different suppliers. The BTS houses the radio
transceivers that define a cell and handle the radio link pro-
tocols with the MS. Depending on the density of the area,
more or fewer BTSs are needed to provide the appropriate
capacity to the cell. Digital communications system (DCS)
networks working at 1800 MHz need twice the number of
BTSs to cover the same area as GSM networks, but provide
twice the capacity.
The BSC manages the radio resources for one or more
BTSs via the standardized Abis interface. It handles radio
channel setup, frequency hopping, and handovers. The BSC is
the connection between the MS and the mobile switching cen-
ter (MSC). The BSC also takes care of converting the 13 kb/s
voice channel used over the radio link (Um interface) to the
standardized 64 kb/s channel used by the public switched tele-
phone network (PSTN).
The Network Subsystem
The MSC is the main component of the network subsystem.
Its provides the same functionality as a switching node in a
PSTN or integrated services digital network (ISDN), but also
takes care of all the functionality needed to handle a mobile
subscriber such as registration, authentication, location updat-
ing, handovers, and routing to a roaming subscriber. The
MSC also acts as a gateway to the PSTN or ISDN, and pro-
vides the interface to the SMSC.
The international roaming and call routing capabilities of
GSM networks are provided by the home location register
(HLR) and visitor location register (VLR) together with the
MSC. The HLR database contains all the administrative infor-
mation about each registered user of a GSM network along
with the current location of the MS. The current location of
an MS is in the form of a Mobile Station Roaming Number
IEEE Personal Communications • June 2000
 Um air interface A interface MSC
MS

CM
CM ISDN
BSS UP
MAP TUP
MM
MM
BSSAP BSSAP
RM RR
SCCP SCCP SCCP

LAPDm LAPDm
MTP MTP level 3
MTP MTP level 2
MTP level 1
TDMA/FDMA TDMA/FDMA

Message layer Data link layer Physical layer

■ Figure 2. The GSM protocol architecture.

(MSRN), typically the SS7 number of tion over the radio link to transmit
the visited MSC, and used to route a MAP call-related signaling information such
call to the MSC where the mobile is TUP ISUP as the establishment of the signaling
actually located. TCAP and traffic channel between the MS
The VLR is usually located within and the BSS.
the MSC to speed up access to the On the MSC side, the message layer
information required during a call and SCCP is divided into four sublayers. The
simplify the signaling. The content of Base System Substation Application
the VLR is a selection of the informa- MTP level 3 Part (BSSAP) of the MSC provides
tion from the HLR, basically all neces- the channel switching functions, radio
sary information for call control and MTP level 2
resources management, and internet-
provision of the subscribed services, working functions. The Message
for each single mobile currently locat- Transfer Part (MTP) and Signaling
ed in the geographical area controlled MTP level 1 Connection Control Part (SCCP) pro-
by the VLR. tocols are used to implement the data
The network subsystem uses two link layer and layer 3 transport func-
other databases for authentication and ■ Figure 3. The SS7 protocol stack. tions for carrying the call control and
security purposes. The Equipment mobility management signaling mes-
Identity Register (EIR) contains a list sages across the A interface. SCCP
of each MS IMEI allowed on the network. The authentication packets are also used to carry the messages for SMS.
center (AuC) database contains each single PIN stored in the Signaling between the different entity uses the Internation-
MS SIM. al Telecommunication Union (ITU) SS7, widely used in ISDN
and current public networks. SS7 is currently the only element
The GSM Signaling Protocol of the GSM infrastructure capable of packet switching as well
The exchange of signaling messages regarding mobility, radio as circuit switching. It is used to transport control signals and
resources, and connection management between the different short message packets for SMS. The protocol consists of the
entities of a GSM network is handled through the protocol Mobile Application Part (MAP), Transaction Capability
architecture, as shown on Fig. 2. Application Part (TCAP), SCCP, MTP, and ISDN-User Part
The architecture consists of three layers: physical, data (ISUP) or Telephone User Part (TUP). Figure 3 depicts the
link, and message. The physical layer and channel structure SS7 protocol stack.
are described in detail by M. Mouly and M. Pautet [4]. Layer The ISUP provides the signaling functions needed to sup-
2 implements the data link layer using a modified flavor of the port switched voice and data applications in the ISDN envi-
Link Access Protocol (LAPD) to operate within the con- ronment. The TUP provides the basic functionality for call
straints set by the radio path. On the MS side, the message control functions for ordinary national and international tele-
layer consists of three sublayers: connection management phone calls. The TCAP is an application layer protocol. It
(CM), mobility management (MM), and resource manage- allows an application at one node to invoke an execution of a
ment (RR). The CM sublayer manages call-related supple- procedure at another node and exchange the results of such
mentary services, SMS, and call-independent supplementary invocation. It isolates the user application from the complexity
services support. The MM sublayer provides functions to of the transaction layer by automatically handling transaction
establish, maintain, and release a connection between the MS and invocation state changes, and generating the abort or
and the MSC, over which an instance of the CM sublayer can reject messages in full accordance with ITU and American
exchange information with its peer. It also performs location National Standards Institute (ANSI) standards. The MAP
updating, IMSI management, and Temporary Mobile Sub- uses the TCAP services to provide the signaling capabilities
scriber Identity (TMSI) identification, authentication, and required to support the mobile capabilities.
reallocation. The RR sublayer establishes the physical connec- The MTP and SCCP (Fig. 4) correspond to the lower three

IEEE Personal Communications • June 2000 17

 TCAP/ISUP/TUP

mation will always be returned to the SMSC

indicating whether the MS has received the short
message or not. A confirmation will also be
SCCP connection- SCCP connectionless
oriented control control returned to the MS from an SMSC indicating
whether the TPDU has been received successful-
SCCP ly. The software within the MS must be able to
management
decode and store the messages.
SCCP SMS Mobile Terminated (SMS-MT) is the
SCCP ability to receive an SMS message from an
routing control
SMSC and is more ubiquitous, while SMS
Mobile Originated (SMS-MO) is the ability to
MTP
level 3 Signaling message Signaling network send short messages to an SMSC. Messages can
handling handling also be stored on the SIM, which can be
retrieved at a later time. When the phone is not
within coverage or the SIM is full, the SMSC
MTP Signaling link MTP will hold the message and deliver it shortly after
level 2 functions management
the phone comes back into range or there is
space in memory.
MTP
level 1 Signaling data link The SMS Basic Network Architecture
functions
The main components of the SMS network archi-
tecture are shown in Fig. 5.
■ Figure 4. The SCCP and MTP sublayers. When routing a mobile originated short mes-
sage, the SMSC forwards the short message to
the SMS-GMSC. The SMS-GMSC interrogates
the HLR for routing information and sends the
SMSC SMS-GMSC / MSC MS short message to the appropriate MSC. The
SMS-IWMSC
MSC delivers the short message to the MS. On
the other hand, when routing a mobile terminat-
ed short message, the MS addresses the required
SMSC according to its global title. If roaming
abroad the visited public limited mobile network
HLR VLR (PLMN) will route the short message to the
appropriate SMS-IWMSC.
The SMSC identifies each short message unique-
ly by adding a time stamp in the SMS-DELIVER
■ Figure 5. The SMS network architecture.
TP-SCTS field. The short message arrival at the
SMSC is accurate to the second. It is the SMSC’s
responsibility to assure that if two or more short
layers of the open system interconnection (OSI) model (Fig. 4). message arrive within the same second their time-stamps will be
The SCCP sublayer supports connectionless and connection- different.
oriented services to transfer data and Global Title Translation The MS has to be able to receive/submit a short message
(GTT) above MTP level 3 for voice, data, ISDN, and GSM ser- TPDU, and then return a delivery report upon successful
vices. The data transfer is reliable, independent of the underly- reception. It is also responsible for notifying the network
ing hardware, and transparent to users. The protocol employs when it has memory capacity available to receive one or more
logical signaling connections within the SS7 network to ensure messages, if it had previously rejected a short message because
reliability and integrity of the ongoing data transfer. The MTP its memory capacity was exceeded.
is divided into three levels:
• MTP level 1 defines the characteristics of the digital signal- Protocol Architecture
ing link and is equivalent to the OSI physical layer. The protocol layer for SMS is shown in Fig. 6. The short mes-
• MTP level 2 is equivalent to the OSI data link layer and sage transfer layer (SM-TL) services the short message appli-
provides a reliable sequenced delivery of data packets cation layer (SM-AL) and enables it to exchange short
across MTP level 1. messages with a peer as well as receive confirmation of recep-
• MTP level 3 provides congestion control, signaling manage- tion reports from earlier requests.
ment, and message discrimination, distribution,
and routing in a similar way as the OSI network
layer. SMS-Deliver Conveying a short message from the SMSC to the MS
SMS-Deliver-Report Conveying a failure cause
Practical Implementation
SMS-Submit Conveying a short message from the MS to the SMSC
SMS uses the SS7 signaling channel to transmit the
data packet [5], thus allowing a text message to be SMS-Submit-Report Conveying a failure cause
received when the user is making a voice or data
call. An active MS should be able to send and SMS-Status-Report Conveying a status report from the SMSC to the MS
receive a short message Transport Protocol Data SMS-Command Conveying a command from the MS to the SMSC
Unit (TPDU) at any time regardless of whether
there is a speech or data call in progress. A confir- ■ Table 1. TPDU types.

18 IEEE Personal Communications • June 2000

 SMSC SMS-GMSC / MSC MS
SMS-IWMSC
element data (IED) that follows. Each of
these fields is 1 octet long.
SM-AL SM-AL
In the user data, the message can be 7 bits,
8 bits, or 16 bits. If 7-bit data is used and the
header does not end on a 7-bit boundary,
SM-TL SM-TL padding bits are used. This is to ensure that
older mobiles which do not support the TP-UD
SM-RL SM-RL SM-RL SM-RL header can still display the message properly.
Using the IEI allows sending and receiving
of concatenated short messages. The IED field
SM-LL SM-LL SM-LL SM-LL contains all the necessary information for the
receiving entity to reassemble the messages in
the correct order, and is coded as follows:
■ Figure 6. The protocol layer for SMS point-to-point.
• First octet: short message reference num-
ber identifying the message within the same
transaction
The SM-TL exchanges PDUs with its peer entity. The • Second octet: specifies the maximum number of short mes-
short message relay layer (SM-RL) conveys the PDUs via the sages in the concatenated short message, which will not
short message link layer (SM-LL). Refer to GSM 03.40 [2] for exceed 255
further details. • Third octet: identifies the sequence number of the short
message within the concatenated message
SMS Protocol Data Unit Types The minimum header length for concatenated message is 7
There are six types of TPDU at the SM-TL, as listed in Table octets for 8-bit and 16-bit data and 8 for 7-bit data; leaving 133
1. The elements of the SMS-Deliver and SMS-Submit TPDU (140 – 7), 152 (160 – 8), and 66 ((140 – 7)/2) characters for the
are shown in Fig. 7 [2]. The main fields of the TPDU are short message. The maximum length of the message is then
described in this document however for a complete descrip- increased to 38,760 (255*152), 33,915 (255*133), or 16,830
tion of the TPDU please refer to GSM 03.40 [2]. (255*66) depending on the character coding scheme used.

TP-Data-Coding-Scheme
The data coding scheme field (TP-DCS) is used to iden-
tify the coding scheme used by the user data, which can TP-message-type-indicator
be 7- or 8-bit or even Unicode [6], as defined in GSM
03.38 [7].
TP-message-type-indicator TP-reject-duplicate
TP-Validity-Period
The TP-VP field contains an information element
enabling an MS to specify a validity period for the short TP-more-message-to-send TP-validity-period format
message it is submitting. The value specifies how long an
SMSC will guarantee the existence of a short message
before delivery to the recipient has been carried out. TP-reply-path TP-reply-path

TP-More-Message-To-Send
TP-user-data-header-indicator TP-user-data-header-indicator
The SMSC uses the TP-MMS field to inform the MS that
one or more short messages are waiting to be delivered.
TP-status-report TP-message reference
TP-User-Data-Header-Indicator
The 1-bit TP-UDHI field indicates whether the TP-UD
includes an additional header as well as the short message. TP-originating-address TP-destination-address

TP-Protocol Identifier
The TP-PID is used by the MS or SMSC to identify the TP-protocol-ID TP-protocol-ID
higher-layer protocol being used for internetworking
with a certain type of telematic device (Telefax group 3
or 4, Ermes, etc.) TP-data-coding-scheme TP-data-coding-scheme

TP-User-Data (TP-UD)
The TP-UD field is used to carry the short message. It TP-service-center-time-stamp TP-validity-period
can store up to 140 octets of data for point-to-point SMS,
together with a header depending on the setting of the TP-user-data-length TP-user-data-length
TP-UDHI field. The amount of space taken by the header
reduces the amount of data the PDU can carry. Figure 8
shows a representation of the layout of the TP-UD for 7- TP-user-data TP-user-data
and 8-bit data schemes.
The header has at least three fields. The first field,
the information element identifier, is used to identify SMS-deliver SMS-submit
concatenated short messages. Information data length
(IDL) is used to indicate the length of the information ■ Figure 7. An SMS TL-PDU.

IEEE Personal Communications • June 2000 19

 Octets
UDL UDHL IEIa IELa IEDa
Total number of octets
Length indicator
Length indicator
UDL: User data length — 1 octet
UDHL: User data header length — 1 octet
IEIx: Information element identifier x — 1 octet
IELx: Information element length x — 1 octet
IEDx: Information element data x — 1 to n
UDL UDHL IEIa IELa IEDa
Total number of octets
Length indicator
Length indicator
■ Figure 8. SMS-TPDU formats for 7-bit and 8-bit data content.
Short Message Routing Considerations
In Fig. 9, user A in network 1 is sending a short message to
user B in network 3 roaming in network 4 . User A is using
the SMSC in network 1 to submit his short message [8].
The local cellular exchange routes the short message in an
SCCP packet according to the SMSC global title as defined by
the E.164 numbering plan [9]. The SCCP packet is forwarded
from exchange to exchange until it reaches the destination
SMSC (1). The routing has to be set up in all the SCCP switches
along the route for the message to successfully reach the SMSC
in network 1 .
Once the SCCP packet carrying the message arrives at the
destination SMSC, a confirmation message is sent back to the
handset using another SCCP packet (2).
To deliver the short message to user B, the SMSC has to
access the HLR database of his home network. A location
request SCCP packet, based on user B’s mobile number, is
sent by the SMSC (3).
This international SCCP network then routes the location
request SCCP packet to the appropriate HLR. When the
HLR receives the request, it will return the location informa-
tion in another SCCP packet to the SMSC (4).
The SMSC then sends the message to the VMSC of user
B, based on the information received from the HLR (5).
Finally, this VMSC interrogates the VLR (6, 7), and delivers
the message to user B (8). Upon successful delivery a confir-
mation SCCP packet is sent back to the SMSC (9).
Throughout these routing procedures, the SCCP packets
can get lost if one of the cellular exchanges along the route
does not know where to forward the SCCP packet. SCCP
routing is based on the global title used for switches and the
SMSC. The routing information has to be in place in the
international SCCP transit switches for the messages to suc-
cessfully reach their destination. Some international switches
only check the country code prefix (e.g., 44 for the United
Kingdom) and forward the packet to the next exchange, while
others also check for the network prefix (e.g., 447976 for
Orange). If the exchange routing table does not include all
the prefixes allocated to the subscribers, some messages will
be rejected. Incompatible implementation of the SMSC can
20
Octets
IEIb … IEIn Padding SM (7-bit data)
Septet boundary
Total number of septets
IEIb … IEIn SM (8-bit data)
Octet boundary
Total number of octets
also lead to the short message not being understood and
being rejected. All the above-mentioned problems can lead to
packets getting lost along the way with different conse-
quences:
• A negative acknowledgment received by the sender (phone
displaying “message failed” or a similar message) although
the short message reaches its destination (loss of packet 1 )
• Reception of duplicate short messages by user B (loss of
packet 5 or 9 ); could also be due to the timeout value
being set too low in the SMSC
• Or, in the worst case the message might not be delivered at
all (loss of packet 1 , 3 , 4 , 5 )
Even if Fig. 9 shows the most complicated routing scenario
there is still much that can go wrong with short message rout-
ing, and a lot of research is currently underway to overcome
these.
Protocols for
Short Message Submission
The European Telecommunications Standards Institute
(ETSI) specified a protocol for short message submission as
part of the overall GSM standard [10]. This specification
defines three interface protocols for the transfer of SMS short
messages between an MS and terminal equipment (TE) via an
asynchronous interface. The protocols clearly overlap in func-
tions, and it is not clear why three have been defined.
Block Mode
The block mode is a binary protocol which encapsulates the
SMS PDU used for short message transfer between an MS
and the SMSC defined in GSM 03.40 [2]. This protocol
includes error detection and is suitable for use where the
link between the application and the phone is subject to
errors. It will be of particular use where control of remote
devices is required. The application has to construct a bina-
ry string including a header and the short message PDU
(SMS-TPDU).
Once the application has requested the phone to enter
block mode a group of functions is available:
IEEE Personal Communications • June 2000
 Originator Recipient
1 network visited network 4

(1) (1) (1) (5) (5) (8) User B

User (2) (2) (2) (9) (9) (9)
A
BSC/BSC VMSC BSC/BSC
Local (6)(7)
Local International International SCCP switch
SCCP switch SCCP switch SCCP switch

(1) (2) (5) (9) VL

R

Foreign SMSC
2 network Recipient 3
home network
(1) (1)
(2) (2)
(3) (3) (3) (3) (3) HL
(4) (4) (4) (4) (4) R
(5) (5) (5)
(9) (9) (9)
Local
SMSC Local International International SCCP switch
SMS-IWMSC SCCP switch SCCP switch SCCP switch (x): Message number

■ Figure 9. International short message routing.

• Submit a short message
• Delete messages from the phone
• List messages in the phone
• Transfer all messages or one from the phone to the application
• Set the phone so that the application is notified every time
a new short message is received
Each of these commands contains a number of predefined
elements as described in the specification. For example, the
Insert Message command format used to submit a short mes-
sage is depicted in Table 2.
Text Mode
Text mode is a character-based protocol based on the AT
command set modified for GSM. This mode is suitable for
unintelligent terminals or terminal emulators, and for applica-
tion software built on command structures like those defined
in ITU V25ter. The application passes the message in plain
text to the phone that constructs the TPDU (Table 3). This
means that text mode offers a lot less functionality than block
Information element Meaning Length byte
Message type Insert SMS type: the value defined 1
in the specification is 0x07
or PDU mode. The text mode does not support or automati-
cally pass incoming messages to the application (only notify it).
PDU Mode
PDU mode is very similar to text mode, except that it leaves to
the application the responsibility to build the short message
TPDU. This mode adds to the convenience of the AT command
set the possibility to construct more sophisticated PDUs (i.e.,
allowing binary data to be transmitted, not just characters).
SEMA SMS2000
Sema Group Telecoms developed SMS2000 as an implemen-
tation of a GSM SMSC [11]. The specification mainly
describes the delivery of short messages to MSs, but also spec-
ifies the protocols for short message submission. The protocol
has been designed to operate over a variety of interfaces such
as X25, DECnet, and SS7. The SMS2000 SMSC is usually
accessed via the general X25 access gateway -either using a
radio Packet Assembler Disassembler (PAD) or a dedicated
link to the message center.
Once connected to the SMSC, an SME can
request any of the operations listed in Table 4. The
SMS2000 SMSC can also send the commands listed
in Table 5 to an SME.

Insert type 1. Store in phone 1

SME SMSC
2. Send, or
3. Store and send
Submit SM
RP-dest. address Address of recipient as defined 1–12
by GSM 04.01 SM submission status
SMS-TPDU As defined by GSM 03.40 Max. 140

■ Table 2. Short message submission using block mode.

SM delivery status report

AT+CMGS=”44976123456”<CR> Send a message to 44976123456

This is a text message<CR> Invoke (submit SM)
^Z

+CMGS=3 Message accepted by the phone with

OK a reference number 3
■ Figure 10. Short message submission using
■ Table 3. Short message submission using text mode. SMS2000.

IEEE Personal Communications • June 2000 21


A transaction between the SME and the SMSC involves
one party sending a request with a status report sent back on
completion or failure of the request. Figure 10 depicts the
submission of a short message from an SME to the SMS2000
SMSC.
The transaction is initiated by the SME when a Submit SM
invoke is sent to the SMSC. The SMSC responds with a result
message indicating that the short message has been accepted
and is being processed. Upon delivery the SMSC notifies the
SME (if a status report has been requested). The SME then
acknowledges the SR, thus completing the transaction.
Since the SMEs connected to the SMS2000 SMSC are
assumed to be trusted systems, a basic transaction will not
include any exchange of login and password between the SME
and the SMSC. However a login facility is still provided in
order to access the SMSC from a different location (i.e., PAD).
Text-Based Protocols
Usually these protocols are proprietary and developed as an
interface to the SMSC of a digital cellular network operator.
The advantage of a text-based protocol is that the user does
not need any special client software to submit a short mes-
sage; they can dial the appropriate message center using any
terminal emulation software and submit short messages
using the different options offered. Figure 11 describes the
submission of a short message using the Telenote-text based
protocol.
There are, however, key disadvantages with text-based pro-
tocols: they offer limited support for extended character sets,
and only work one way, to name a few. The user is only able
to send messages and receive confirmation of submission. The
SMSC is unable to notify the end user of successful delivery.
Submit SM Send an SM to an MS
Delete SM Delete a previously submitted SM
Replace SM Replace a previously submitted SM to an MS.
Delete all SM Delete all previously submitted and undelivered SM to an MS
Enquire SM Request status of a previously submitted SM
Cancel SRR Cancel all status report requests (SRR) about a previously
submitted SM.
Alert SME request Request to be alerted when a specified SME becomes
registered.
Retrieve Request Request transmission from the SMS2000 SMSC of any
pending SM or SR.
Login For X25 general access when accessing from a different
location
Change Password For X25 general access when accessing from a different
location
■ Table 4. SMS2000 commands.
Alert SME Indicates a MS has registered with the GSM network
Status Report Indicates successful delivery or failure of a previously
submitted SM.
Incoming SM Indicates an incoming SM is being held by the SMS2000
SMSC
■ Table 5. Additional SMS2000 commands.
22
PLEASE ENTER THE MOBILE NUMBER IN
INTERNATIONAL FORMAT, E.G.
44385XXXXXX, FOLLOWED BY RETURN, (OR
RETURN TO QUIT).
>44374164828
PLEASE TYPE YOUR TELENOTE, (MAXIMUM
160 CHARACTERS), FOLLOWED BY RETURN.
>This is a test message
MESSAGE ACCEPTED
■ Figure 11. Short message submission using Telenote.
Telocator Alphanumeric Protocol
Developed by Telecom Securicor Cellular Radio Limited, the
Telocator Alphanumeric Protocol [12] provides greater flexi-
bility and more features than text-based protocols. The overall
performance is also significantly more efficient.
In its fully featured implementation, the protocol allows
the user to perform the following operations:
1. Submit a short message and receive confirmation of accep-
tance.
2. Submit a short message and receive status of the first deliv-
ery attempt.
3. Query the current status of a message submitted by 1 or 2.
4. Delete a message submitted by 1 or 2.
5. Replace a message submitted by 1 or 2, unless the message
has already been delivered to the mobile.
6. Update a message submitted by 1 or 2. If the message is
still in the SMSC. it is replaced; otherwise, a new message
is sent to the mobile.
TAP is a session-based protocol, as opposed
to a permanently connected one. Each session
comprises a logon, a number of transactions, and
a logoff, as shown on Fig. 12.
Other Submission Protocols
Many others protocols have been designed and
operate over a wide range of hardware interfaces
(UCP, CIMD, SMPP, etc.). Most of the protocols
can be classified as dumb or smart based on
whether they provide notification of delivery
and/or advanced functionality (message deletion,
replacement, etc.). We chose to discuss the pro-
tocols used in the United Kingdom as an example
of the different possibilities offered to subscribers
and software developers.
Current Issues
SMS is increasingly popular; the barrier of 100
million messages in a month was recently reached
in the United Kingdom. As growing numbers of
users start to realize that GSM has more to offer
than crystal clear voice calls, the services offered
are likely to evolve even more rapidly, and it is
quite likely that data calls and short messages will
soon represent an important part of the overall
GSM traffic.
New protocols are now being designed that
will allow even more advanced functionality to be
implemented in client software. Some of the fea-
tures under development include:
• Support for message concatenation to allow up
to 255 messages to be submitted as part of the
IEEE Personal Communications • June 2000
 SME SMSC
<CR>
ID=
<ESC>PG1<Password><CR>
<CR><ACK><CR>
<ESC>[p<CR>
<STX><MISDN><CR><Message><CR><ETX><Checksum<CR>
<Message response><CR><ACK><CR>
■ Figure 12. Short message submission using TAP.
same transaction
• Support for distribution list creation and modification with-
in the SMSC to greatly increase short message throughput
Last but not least, some research projects are studying the pos-
sibility of using SMS as an alternative layer to TCP/IP, thus
adding mobility to low-bandwidth applications. Intel’s Narrow
Band Socket specification first tried to define how applications
could benefit by using SMS as an alternative to TCP/IP; however,
this work is now in the process of being superseded by the Wire-
less Application Protocol (WAP).
References
[1] ETSI GSM 3.41, “Digital Cellular Telecommunication System (Phase 2);
Technical Realisation of Short Message Service Cell Broadcast (SMSCB),”
v. 5.2.0, May. 1996.
[2] ETSI GSM 3.40, “Digital Cellular Telecommunications System (Phase 2+)
Technical Realisation of the Short Message Service Point-to-Point,” v.
4.13.0, May. 1996.
[3] J. Scourias, “A Brief Overview of GSM,” Univ. of Waterloo; http://ccnga/
uwaterloo.ca/~jscouria/GSM/gsmreport.html
[4] M. Mouly and M. Pautet, “The GSM System for Mobile Communica-
tions,” 1992.
[5] W. Roth, “Data Service on the GSM Platform,” GSM Summit Hong
Kong, Mar. 1993.
[6] ISO/IEC10646, “Universal Multiple Octet Coded Character Set (USC),
UCS2, 16 Bit Coding.”
[7] ETSI GSM 3.38, “Digital Cellular Telecommunications System (Phase 2+):
Alphabets and language-specific information,” v. 5.2, May. 1996.
[8] K. Holley, http:/ftp.labs.bt.com/people/holleyka
[9] CCITT E.164, “Numbering Plan of the International Telephone Service,”
v. 5, 1997.
[10] GSM 07.05, “Digital Cellular Telecommunications System (Phase 2);
Use of Data Terminal Equipment — Data Circuit terminating; Equip-
ment (DTE - DCE) interface for Short Message Service (SMS) and Cell
Broadcast Service (CBS),” draft, May 1996.
[11] SEMA Group Telecommunications, “SMS2000 v. 4.0, Open Interface
Specification,” INS/FS/28.
IEEE Personal Communications • June 2000
[12] Telocator Alphanumeric Protocol (PCIA) v. 1.2 Functional Spec for TAP-
AIM ver 2.6 (Aldiscon)
Additional Reading
[1] M. Rahnema, “Overview of the GSM System and Protocol Architecture,”
IEEE Commun. Mag., vol. 3, no. 4, Apr. 1993, pp. 92–100.
Biographies
GUILLAUME PEERSMAN (G.Peersman@dcs.shef.ac.uk) graduated from the Insti-
tut Superieur d’Electronique de Paris (ISEP) in 1996 with a double M.Eng.
in electronics and computer networks. He then joined the University of
Sheffield, and is currently reading for a Ph.D. degree in the Computer Sci-
ence Department. His research interests focus on the development and per-
formance analysis of two-way messaging gateways for the GSM Short
Message Service. He also recently extended his field of research to the
Wireless Application Protocol gateway design.
SRBA R. CVETKOVIC (S.Cvetkovic@dcs.shef.ac.uk) completed his B.Sc. (with
First Class Honours) and Ph.D. degrees in electronic and electrical engineer-
ing at City University, London (1983) and University College London (1987),
respectively. In June 1987, he joined the Department of Electronic and Elec-
trical Engineering at the University of Surrey as a lecturer in telecommuni-
cations and satellite systems. In September 1992 he moved to the
Department of Electrical Engineering and Electronics, Brunel University,
West London, to a senior lectureship in data communications. In Septem-
ber 1995 he took up the post of senior lecturer in multimedia communica-
tions systems in the Department of Computer Science at the University of
Sheffield. In January 1996 he established the Centre for Research, Education
and Development Online (CREDO). He now leads the Research Group in Com-
munications and Distributed Systems (CDSRG), which he co-founded in Octo-
ber 1997 with Prof. Colin Smythe. CDSRG (including CREDO) is currently
involved in projects of value in excess of US$8.5million and has over 35 full-
time members of academic, research, and support staff. In October 1997 he
was promoted to reader (in telematics) and in June 1999 to a personal chair
in mobile systems, a joint position between the Departments of Electronic and
Electrical Engineering, and Computer Science. His research interests include
multimedia/broadband communication systems, satellite communications and
DSP systems, as well as numerical modeling and measurements of electro-
magnetic fields. More recently, his focus has been on protocols for supporting
mobile systems (Mobile IPv6, GSM/SMS) and knowledge management. For
further information visit http://www.dcs.shef.ac.uk/~srba
PAUL GRIFFITHS (P.Griffiths@dialogue.co.uk) graduated from Sheffield City Poly-
technic in 1986 with a B.Sc. Hons. in business studies. He then joined
Fretwell Downing Data Systems as a software developer where he worked on
various projects between 1998 and 1991. Between 1991 and 1994 he
worked on secondment with Sheffield Hallam University to conduct research
into the development of GUI environments. In 1994 he helped to found Dia-
logue Communications Limited who developed a product for GSM short
messaging called pagemail which has since sold over 500,000 copies. He has
since been involved with both business and technical aspects of developing
server products for GSM SMS. He is now co-director of Dialogue Communica-
tions Ltd., a specialist SMS software manufacturer which has recorded an
average growth rate of 70 percent for the last three years.
HUGH SPEAR (H.Spear@dialogue.co.uk) received an M.Sc. with distinction in
Software Systems Technology from Sheffield University in 1991. Between
1991 and 1995 he worked as a systems analyst and project leader with
Fretwell-Downing Data Systems in Sheffield. In 1995 he co-founded Dia-
logue Communications Limited, a mobile messaging business which devel-
ops and markets products and services for messaging over GSM SMSand
paging services. By the end of 1999 Dialogue had over 250,000 customers
and products in over 20 countries.
23