Handling SMS

9.
SMS Messages
This chapter explains the SMS-related AT commands. SMS messages

are sent in a PDU format. This presupposes that you know how to
construct a PDU. In this chapter, information concerning how to
construct PDUs is provided.
9.1 About SMS

SMS stands for Short Message Service. SMS provides a means of
sending messages of limited size from and to GSM mobile stations.
SMS uses something called a Service Centre which acts as a store and
forward centre for SMS messages.
Two different types of SMS services are explained as follows:
• Mobile Originated (MO) – A mobile-originated SMS is transported
from a mobile station to the Service Centre. These may be intended
for other mobiles or may even be intended for other services which
the GSM network and Service Centre support.
• Mobile Terminated (MT) – A mobile-terminated SMS will be
transported from a Service Centre to a Mobile Station.
9.2 About the PDU
9.2.1 What is a PDU?
General
The abbreviation PDU stands for Protocol Data Unit (it can also stand
for Packet Data Unit, the two different meanings are in use). These data
units represent how digital information is coded and structured when it
is sent over the air interface.
149
EN/LZT 123 922 R1A
GM 32 INTEGRATOR’S MANUAL
When we use a mobile phone, we usually enter a text message on the

keypad of the phone, give it a phone number to be sent to, press the
"YES" button, and, usually, receive a "MESSAGE SENT" notification
from the phone. With a GSM module this process has to be performed
with AT commands from a terminal of some kind since there is no
keyboard. In some cases, the module does not support text mode SMS
and the message must be coded as a PDU.
There are different types of PDUs involved in the SMS messaging
process, SMS-REPORT, SMS-COMMAND, and so on. We will,
however, only be addressing two different types here, as they are likely
the two most important types.
SMS-SUBMIT PDU: This PDU, related to Mobile originated SMS, is
sent from one mobile terminal to the service centre.
SMS-DELIVER PDU: This PDU, related to Mobile terminated SMS, is
received by a mobile from the service centre.
Definition
A PDU is a Service Centre Address (SCA) that is followed by a
Transport Protocol Data Unit:
PDU = SCA + TPDU
An SMS-SUBMIT PDU can look like this:
07916407058099F911000A8170607896200000A71554747A0E4ACF
416110945805B5CBF379F85C06
The SCA portion of the string is shown in bold. The remaining string is
the TPDU.
The PDU format is a hexadecimal encoded binary format. This means
that 2 hexadecimal digits represent one byte of data. When one refers to
Data being transmitted, a byte is usually called an octet (bytes are stored
and octets are transmitted). The TPDU consists of a header containing
control information and a "payload" containing the User Data. The
different parts of the TPDU will be described later in more detail.
Some Modules and mobiles will only support the TPDU format, not the
PDU format. In that event, you must simply remove the SCA and work
with TPDU only.
Tip! In the file PDU.C, in the Software Program GM 22, in the Development
Kit, you can find the source code (a C application) that will translate text
messages into PDU mode. With some manipulating this code can be
used and incorporated into your application to convert text to PDU
automatically.
150
EN/LZT 123 922 R1A
SMS MESSAGES
Features
The PDU mode affords the user more control over the information to be
sent and the way which it is sent. For instance, the sender may not want
to send a text message, but may wish, instead, to send raw Data. PDU
format will allow the sender to send raw data.
Since it is possible to change the SCA in the PDU, the SMS messages
can be sent via any Service Centre, as long as this is permitted by the
network operator. The SCA, in the PDU, is changed by the use of AT
commands. The SCA is stored in the SIM card and taken from there.
The SCA must not be included in the PDU.
To use the default SCA (from the SIM card) in the PDU, the SCA
portion of the PDU is replaced with 00. The PDU is then:
0011000A8170607896200000A71554747A0E4ACF416110945805B
5CBF379F85C06
9.2.2 The Transmission Order
Octets in a PDU are transmitted according to their order. Octets

appearing at the beginning of the PDU are transmitted first. The same
process applies to the individual bits contained in the octets. Thus, the
low order bits are transmitted first. Below is an example of octet
transmission:
Example! The following octet is sent from one mobile to another: 03FFFFE0.
A table using the binary representation is as follows:
Binary representation
Octet
7 6 5 4 3 2 1 0
03 0 0 0 0 0 0 1 1
FF 1 1 1 1 1 1 1 1
FF 1 1 1 1 1 1 1 1
E0 1 1 1 0 0 0 0 0
The transmission order would be as follows (the first bit sent being the
rightmost):
11100000111111111111111100000011
151
EN/LZT 123 922 R1A
9.2.3 Representations
There are a few different meanings given to the hexadecimal

representations. The information in a PDU takes the form of pure
hexadecimal integers, decimal digits, and alphanumeric information
(although still represented as hexadecimal).
For instance some fields in the PDU are truncated into one octet, and
they will be seen as a hexadecimal number. One octet is two
hexadecimal digits.
Sometimes the information appears to be decimal digits. For a decimal
digit only a half octet (4-bits) is required.
Alphanumeric representation is based on the default alphabet defined
later in this manual and in GSM 03.38. This mainly applies to the User
Data.
By following the examples in the text, issues concerning
representations will be resolved.
9.3 SMS-SUBMIT
An SMS-SUBMIT PDU is the type of PDU sent to another mobile. This
is, therefore, what is submitted to the service Centre to be delivered to
the chosen destination.
Follow the example below to understand the various fields of a TPDU
included in the SMS-SUBMIT PDU. The entire PDU (PDU = SCA +
TPDU) will be considered when discussing the SMS-SUBMIT and the
SMS-DELIVER types of TPDU's.
Example! This example is a follow-up from the earlier sections:
07916407058099F911000A8170607896200000A71554747A0E4ACF
416110945805B5CBF379F85C06
Start by breaking the string down into the various fields:
9.3.1 The Service Centre Address (SCA)
07916407058099F911000A8170607896200000A71554747A0E4ACF
416110945805B5CBF379F85C06
152
EN/LZT 123 922 R1A
SMS MESSAGES
This is the Service Centre Address (SCA). It has its own special address
field. It is broken down as follows:
Binary representation Field meaning

Octet
7 6 5 4 3 2 1 0
07 0 0 0 0 0 1 1 1 Address length- This octet

declares the number of
octets to follow.
91 1 0 0 1 0 0 0 1 This is the type of Address

field. See below for more
details.
64 0 1 1 0 0 1 0 0 The digits 4 and 6
07 0 1 1 0 0 1 0 0 The digits 7 and 0
05 0 0 0 0 0 1 0 1 The digits 5 and 0
80 1 0 0 0 0 0 0 0 The digits 0 and 8
99 1 0 0 1 1 0 0 1 The digits 9 and 9
F9 1 1 1 1 1 0 0 1 The digit 9. Since there are an

odd number of digits in this
SCA then the bits 4-7 in this
octet are fill bits.
Type of Address Octet

There are two different fields in this octet. Bites 0-3 are the Numbering
plan Identification. Bits 4-6 are the type of number. Bit 7 is a fill bit. The
Type of Address Octet has two fields as shown in the following table.
7 6 5 4 3 2 1 0
1 Type-of-number Numbering-plan-identification
The values for the two fields, Type of number and Numbering-plan-
identification, can be chosen according to the table below:
Bit number Bit value Description
7 1, always Fill bit
153
EN/LZT 123 922 R1A
000 Unknown
001 International number
010 National number
011 Network specific number

Type-of-number
6,5,4 100 Subscriber number
101 Alphanumeric, (coded according to GSM

TS 03.38 7-bit default alphabet)
110 Abbreviated number
111 Reserved for extension
0000 Unknown
0001 ISDN/telephone numbering plan
0011 Data numbering plan (X.121)
0100 Telex numbering plan

Numbering-plan-
identification
1000 National numbering plan
3,2,1,0
1001 Private numbering plan
1010 ERMES numbering plan
1111 Reserved for extension
All other values are reserved
With this information, it will be possible to understand the SCA

address:
07916407058099F9
• After the first octet, there are 7 octets that follow in the SCA address
field.
• Upon closer examination at the example, we see that the octet for the
Type of address is 91. According to the table above, this means that
we have an international number and that the number uses the ISDN/
telephone numbering plan.
• From the rest of the SCA, we can see that we have an international
number: 46 705008999 (46 it the country code for Sweden)
Upon comparing this number with the SCA number, we discover that
the received number is simply the reversed paired digit of the SCA
number. In summary, the telephone number is converted into a PDU
format in the following way:
1. Write down the number (international or domestic format does not matter):
46705008999F
154
EN/LZT 123 922 R1A
SMS MESSAGES
2. If the telephone number contains an odd number of digits, add an F at the

end. This is due to the fact that the number will need fill bits (represented
by the hexadecimal F) in the last octet: 46705008999F
3. Pair the numbers: 46 07 50 08 9F
4. Reverse the digits: 64 07 05 08 99 F9
As mentioned in previous sections, you can use the default SCA stored
in the SIM card. The SCA is just replaced with a 00 which means that
the SCA is of zero length. The mobile or module should be equipped to
find the SCA on the SIM.
9.3.2 The Next Octet (TP-MTI, TP-RD, TP-VPF, TP-SRR, TP-UDHI, TP-RP)
The next octet after the SCA address contains six fields. The same
example as before is presented:
The octet is marked in bold. The fields are as follows:
Bit number Description
7 Reply Path (TP-RP)
6 User data header indicator (TR-UDH)
5 Status report request (TP-SRR)
4
Validity Period format (TP-VPF)
3
2 Reject duplicates (TP-RD)
1
Message type indicator (TP-MTI)
0
In the following subchapters, a description of the fields will be

provided.
155
EN/LZT 123 922 R1A
Message Type Indicator (TP-MTI)

This 2-bit field denotes which type of SMS is represented by the PDU
according to the table below. Notice that the meaning depends upon
which "direction" the message is travelling. From the Service Centre to
the Mobile, or from the Mobile to the Service Centre.
Message type
Bit 1 Bit 0 Direction SC-MS Direction MS-SC
0 0 SMS-DELIVER SMS-DELIVER REPORT
1 0 SMS-STATUS REPORT SMS-COMMAND
0 1 SMS-STATUS REPORT SMS-SUBMIT
1 1 RESERVED
In this document, only SMS-SUBMIT and SMS-DELIVER PDUs will

be addressed.
Reject Duplicates (TP-RD)

This 1-bit flag is located in Bit 2 of the octet in question. This field
indicates whether or not the Service Centre shall accept an "identical"
SMS from the same originating Mobile when the original SMS is still
held at the Service Centre. The comparison is made using the TP-MR
and TP-DA fields only. These fields are explained in sections 9.3.3, The
Message Reference Field (TP-MR) on page 158 and 9.3.4, The
Destination Address (TP-DA) on page 159. Usually this parameter is
left as 0 which means that the Service Centre should accept duplicates.
Validity Period Format (TP-VPF)

This is a 2-bit field, and it describes the format used for a parameter that
appears later in the PDU, the validity period (TP-VP). The validity
period basically informs the Service Centre about how long it should
hold on to an SMS before discarding it, when the destination is
unreachable.
There are four different options for the validity period, which can be
chosen according to the following table:
Bit 4 Bit 3 Description
0 0 No validity Period will be present.
1 0 Relative format used for the Validity Period.
0 1 Enhanced format used for the Validity Period.
1 1 Absolute format used for the Validity period.
156
EN/LZT 123 922 R1A
SMS MESSAGES
Since relative format is typically sufficient, it is the only format

addressed in detail in this document.
Status Report Request (TP-SRR)

This is a 1-bit flag found in bit number 5 of the octet in question. It
basically requests the type of SMS to be returned to the Mobile after the
SMS-SUBMIT is sent to the Service Centre. There exists an SMS of
type SMS-STATUS REPORT where the status of previously sent SMSs
is reported. Note that not all mobile stations and networks support this
type of SMS.
If 1 is transmitted, a status report is requested, otherwise 0 will appear.
This parameter can generally be set to 0.
User Data Header Indicator (TP-UDHI)

This is another 1-bit field found in bit 6 of the octet in question. This
parameter describes what the User Data field, TP-UD (explained further
below) will contain. If the value is 1, the User Data field will contain a
User Data Header in addition to the short message, otherwise the field
will only contain the short message.
Most mobiles do not support the User Data Header format. It is intended
for future use with compressed SMS messages, SIM toolkit messages,
and Concatenated SMS messages. Normally the value of this parameter
is 0. No further details concerning User Data Header are considered in
this document. Details about the usage of User Data header are found in
the GSM specification GSM 03.40.
Reply Path (TP-RP)

The reply path field is a 1-bit field in bit 7 of the octet in question. This
parameter signals whether a reply is requested from the receiving
mobile station.
• If a reply path is requested, the replying mobile station will try to use
the same Service Centre that the sending mobile used. This is to
enhance the probability of delivery of the reply. Also, the recipient
of the SMS might not have the SMS function available on their
subscription. Setting the reply path nevertheless, gives them the
opportunity to answer any SMS. Which party pays for the reply
depends on the operator.
If this parameter is set to 1, the reply path is set, otherwise 0 will appear.
157
EN/LZT 123 922 R1A
Explanation of Our Example

After considering the information in the previous sections, it is possible
to understand the example used in this chapter. The value of the PDU is
11:
7 0 (TP-RP)
6 0 (TP-UDH)
5 0 (TP-SRR)
4 1
(TP-VPF)
3 0
2 0 (TP-RD)
1 0
(TP-MTI)
0 1
• According to the table, the TP-MTI is set to 0. An SMS is sent from

the mobile to the Service Centre. This means that this is a SMS-
SUBMIT type of PDU.
• TP-RD is 0, as we do not want the Service Centre to reject any
duplicates that we may send.
• TP-VPF is 10, which means that the PDU uses the relative Validity
Period field format.
• TP-SRR is 0, therefore, no Status Report is requested.
• TP-UDIH is 0, which means that there is no User Data header within
the User Data.
• No Reply Path is set since the TP-RP is set to 0.
9.3.3 The Message Reference Field (TP-MR)
Have a look at the example once more, and the next octet:
07916407058099F911000A8170607896200000A71554747A0E4ACF
416110945805B5CBF379F85C06
This is the Message reference field (TP-MR). This field is 1 octet in
length. It is a hexadecimal representation of an integer reference
number given to the SMS-SUBMIT. The number can range from 0-255
in value. The user can set the number to any value, although usually it
is set to 00.
The user can use this field to keep track of sent delivered and received
SMSs. In the example, the message reference field has been set to 00.
158
EN/LZT 123 922 R1A
SMS MESSAGES
9.3.4 The Destination Address (TP-DA)
The destination address is shown in the following example below:

07916407058099F911000A8170607896200000A71554747A0E4ACF
416110945805B5CBF379F85C06
This field represents the mobile number to which the SMS is intended.
It is almost identical to the address field discussed earlier for the Service
Centre. There is only one difference, in the first octet.
Recall that in the Service Centre Address it was the number of octets to
follow in the address field. Now, however, it is the number of digits in
the destination mobile subscriber number.
The rest is identical to the Service Centre Address as mentioned above.
In the following table, the destination address 0A817060789620, in our
example, is broken down:
Binary representation Field meaning

Octet
7 6 5 4 3 2 1 0
0A 0 0 0 0 1 1 0 1 Address length- This is the

number of digits in the
Destination mobile number.
81 1 0 0 0 0 0 0 1 This is the type of Address

field. See below for more
details.
70 0 1 1 1 0 0 0 0 The digits 0 and 7
60 0 1 1 0 0 0 0 0 The digits 0 and 6
78 0 1 1 1 1 0 0 0 The digits 8 and 7
96 1 0 0 1 0 1 1 0 The digits 6 and 9
20 0 0 1 0 0 0 0 0 The digits 0 and 2
• The Address length dictates that the mobile number will consist of
10 digits.
• The Type of Address field is 81. This means that the Type of
Number is National and the Numbering plan is ISDN/telephone
numbering plan.
Reconstructing the mobile number gives:
70 60 78 96 20
The complete number is thus:
070-6876902
This is a domestic number. Notice that since the number has an even
number of digits no fill bits are required!
159
EN/LZT 123 922 R1A
9.3.5 The Protocol Identifier (TP-PID)
In our example, the Protocol Identifier is shown below:

07916407058099F911000A8170607896200000A71554747A0E4ACF
416110945805B5CBF379F85C06
The use of this octet is of particular interest. It provides some useful
functions for SMS. The octet describes the higher-level protocols or
interworking devices which the SMS is intended for or has been
delivered from.
The Service Centre of your network operator may support certain
services. For instance, it might be capable of converting your SMS to E-
mail, Paging messages, Telex, Teletex, SIM Tool kit information or
visa versa. It all depends upon what is connected (interworked) to the
Service Centre. This TP-PID field communicates to the Service Centre
the specific service for which the SMS is intended or even which service
the PDU has come from.
Since we are sending information between mobile stations only, we can
assume that this Octet is set to 00.
For more information concerning the field’s full properties and how to
use it, please refer to the GSM specification GSM 03.40. You might
also want to consider contacting your network operator for more
information on the services available.
160
EN/LZT 123 922 R1A
SMS MESSAGES
9.3.6 The Data Encoding Scheme (TP-DCS)
The Data Encoding Scheme is given in the following octet of the SMS-
SUBMIT:07916407058099F911000A8170607896200000A71554747
A0E4ACF416110945805B5CBF379F85C06
Table 1: The Data Encoding Scheme octet and what it means:
Encoding Use of
Group Bits bits 3 - 0
7-4
00xx General Data Encoding indication.

Bits 5-0 indicate the following:
Bit 5 = 0, indicates the text is uncompressed.

Bit 5 = 1, indicates the text is compressed using the GSM
standard compression algorithm (see GSM 03.42).
Bit 4 = 0, indicates that bits 1 to 0 are reserved and have no

message class meaning
Bit 4 = 1, indicates that bits 1 to 0 have a message class
meaning:
Bit 1 Bit 0 Message Class

0 0 Class 0
0 1 Class 1 Default meaning: ME-specific
1 0 Class 2 SIM specific message
1 1 Class 3 Default meaning: TE specific
(GSM 07.05)
Bits 3 and 2 indicate the type of alphabet in use, as follows:
Bit 3 Bit 2 Alphabet:

0 0 Default alphabet
0 1 8 bit data
1 0 UCS2 (16 bit)
1 1 Reserved
NOTE: The special case of bits 7-0 being 0000 0000 indicates
the Default GSM Alphabet.
Values 0100
through
1011 Reserved encoding groups.
1100 Message Waiting Indication Group: Discard Message
Bits 3-0 are encoded exactly in the same as Group 1101,

however, with bits 7-4 set to 1100 the mobile may discard
the contents of the message and only present the indication
to the user.
1101 Message Waiting Indication Group: Store Message
This Group allows an indication to be provided to the user

concerning the status of the types of messages waiting on
systems connected to the GSM PLMN. The mobile may
present this indication as an icon on the screen or other MMI
indication. The mobile may take note of the Origination
Address for messages in this group and group 1100. For each
indication supported, the mobile may provide storage for
the Origination Address which is used to control the mobile
indicator. Text included in the user data is coded in the
Default Alphabet.Where a message is received with bits 7-4
set to 1101, the mobile will store the text of the SMS message
in addition to setting the indication. Bit 3 indicates Indication
Sense:
161
EN/LZT 123 922 R1A
Table 1: The Data Encoding Scheme octet and what it means:
Encoding Use of
Group Bits bits 3 - 0
7-4
Bit 3
0 Set Indication Inactive

1 Set Indication Active
Bit 2 is reserved and set to 0
Bit 1 Bit 0 Indication Type:
0 0 Voice mail Message Waiting

0 1 Fax Message Waiting
1 0 E-Mail Message Waiting
1 1 Other Message Waiting*
Mobile manufacturers may implement the "Other Message

Waiting" indication as an additional indication without
specifying the meaning. The meaning of this indication is
intended to be standardized in the future, so Operators
should not make use of this indication until the standard for
this indication is finalized.
1110 Message Waiting Indication Group: Store Message
The encoding of bits 3-0 and the functionality of this feature

are the same as for the Message Waiting Indication Group
above, (bits 7-4 set to 1101) with the exception that the text
included in the user data is coded in the uncompressed
UCS2 alphabet.
1111 Data encoding/message class
Bit 3 is reserved and set to 0.
Bit 2 Message encoding

0 Default alphabet
1 8 bit data
Bit 1 Bit 0 Message Class:

0 0 Class 0
0 1 Class 1 ME-specific
1 0 Class 2 SIM-specific
1 1 Class 3 TE-specific (see GSM 07.05)
The Data Encoding Scheme describes how the User Data (TP-UD) is
encoded, which type of alphabet/character set is used, and the CLASS
the SMS. We will look at TP-UD later; however for now, let us view the
table concerning how to set the Data Coding Scheme octet and what it
means:
Explanations for the Data Coding Scheme Table

• The default GSM alphabet indicates that the User Data has been
encoded using a 7-bit alphabet. This is discussed in section 9.3.9,
The User Data (TP-UD) on page 165. If the 7-bit alphabet is used,
up to 160 characters can be sent in an SMS.
162
EN/LZT 123 922 R1A
SMS MESSAGES
• Other alphabets can be used as well. For instance, any 8-bit alphabet
which is agreed upon by the sender and receiver. It is also possible to
send 16-bit Unicode (UCS2).
• There are 4 different types of SMS classes and one type of Classless
SMS. The foregoing classes can be described as follows:
Class 0 SMS These are not stored anywhere. They are sent
directly to the telephone display. In a
module, the messages to the TE are
forwarded by means of the AT command
setting AT+CNMI=3,2.
Class 1 SMS These are directed to the mobile equipment
if there is available memory storage,
otherwise it will be stored in the SIM.
Class 2 SMS These are sent directly to the SIM.
Class 3 SMS These messages will typically be transferred
to the terminal equipment or application if
this is requested. This is controlled by the
AT command AT+CNMI (see the relevant
AT command description for more
information about this AT command).
Classless SMS This is usually the type of class sent by a
mobile telephone. It is stored in the available
memory, usually in the telephone.
For a more in-depth explanation and additional information regarding the

different SMS classes and their uses, see the GSM specification 03.38.
In the example, the TP-DCS has the value 00 which indicates a classless
SMS. According to the above mentioned table this means that the Data
will use the default GSM alphabet and that it is intended for mobile-to-
mobile communication.
Other values that could have been chosen are:
• TP-DCS = F0-F3 will give SMS classes 0 to 3 respectively.
• TP-DCS = F4-F7 will give the 8-bit data versions of the SMS above.
When sending 8-bit data from a module to a normal mobile telephone,
the message received will be completely destroyed. This is due to the
fact that a mobile phone can only interpret the GSM alphabet and will
accordingly translate an 8-bit alphabet.
9.3.7 The Validity Period (TP-VP)
The Validity Period is the amount of time the Service Centre will hold
the submitted SMS if the destination address is unreachable. If the
Service Centre has not delivered the SMS after this time period, the
message will be discarded.
163
EN/LZT 123 922 R1A
The field TP-VPF determines the format of the Validity Period field. In
this manual, only one form of the Validity Period, the relative format, is
considered.
In the example, the Validity period is the octet marked in bold 07.
07916407058099F911000A8170607896200000A71554747A0E4ACF
416110945805B5CBF379F85C06
The following table below illustrates how the validity period is
calculated.
TP-VP Value TP-VP Value Validity Period value calculation

(HEX) (HEX)
00-8F 0-143 (TP-VP+1) x 5min (i.e. 5min intervals up to

12hrs)
90-A7 144-167 12hr+((TP-VP-143) x 30min)
A8 168-196 (TPVP-166) x 1day
C5-FF 195-255 (TP-VP-192) x 1week
The value of the TP-VP field in the example is A7. The Validity Period
is calculated by means of the table above:
A7hex = 167decimal
From the table, the formula to use is 12hrs+((TP-VP-143) x 30min).
12hrs+ ((167-143) x 30 min) = 12hrs+ (24 x 30min) = 12hr + 12hr =
24hr We, therefore, have a validity period of one day.
There are two other formats for the Validity Period: Absolute and
enhanced format. Additional information about these formats can be
found in the GSM specification GSM 03.40.
9.3.8 User Data Length (TP-UDL)
The User Data Length specifies the amount of User Data. This is done
in two ways:
1. If the User Data is the default GSM alphabet (settings in TP-DCS will
tell how the User Data is represented), the TP-UDL describes the number
of characters (or number of septets) in the User Data field.
2. If the User Data is 8-bit data (or octet represented), the TP-UDL will
describe the number of octets in the User Data field.
In the example, the User Data Length is the octet 15 marked in bold:
07916407058099F911000A8170607896200000A71554747A0E4ACF
416110945805B5CBF379F85C06
164
EN/LZT 123 922 R1A
SMS MESSAGES
In the section TP-DCS, it was determined that a classless SMS was to

be sent. This assumes that the default GSM alphabet is used. The length
provided below reflects the number of characters in the example
message:
15hex= 21dec. In next section, User Data, we will see the significance
of the term "message" in the phrase "This is a PDU message". The
message has 21 characters.
9.3.9 The User Data (TP-UD)
The User Data can be up to 140 octets. In the example, the User Data is
marked in bold. We are sending a message of 19 octets.
07916407058099F911000A8170607896200000A71554747A0E4AC
F416110945805B5CBF379F85C06
The forgoing data represents characters in the Default GSM alphabet.
According to the previous section, we are sending 21 characters. This
means that 21 characters have to be truncated into 19 octets.
Since the default 7-bit GSM alphabet is used, 160 characters can be
truncated into 140 octets. This means that one octet in the message does
not correspond to one character. The message has to be broken down
into bit-level and then translated into the GSM-character set.
The following table shows the characters for the default GSM alphabet.
So, when we look at the user data, we unfortunately cannot directly
replace each octet with a character. Instead, we have to break the
message down to the bit level and then translate the results information
into the GSM character set.
First, lets take a look at the following character table for the default
GSM alphabet:
B6 0 0 0 0 1 1 1 1
Bit Values B5 0 0 1 1 0 0 1 1
B4 0 1 0 1 0 1 0 1
B3 B2 B1 B0 0 1 2 3 4 5 6 7
0 0 0 0 0 @ ∆ SP 0 ¡ P ¿ p
0 0 0 1 1 £ _ ! 1 A Q a q
0 0 1 0 2 $ Φ " 2 B R b r
0 0 1 1 3 ¥ Γ # 3 C S c s
0 1 0 0 4 è Λ ¤ 4 D T d t
0 1 0 1 5 é W % 5 E U e u
165
EN/LZT 123 922 R1A
0 1 1 0 6 ù Π & 6 F V f v
0 1 1 1 7 ì Ψ ' 7 G W g w
1 0 0 0 8 ò Σ ( 8 H X h x
1 0 0 1 9 Ç Θ ) 9 I Y i y
1 0 1 0 A LF Ξ * : J Z j z
1 0 1 1 B Ø 1) + ; K Ä k ä
1 1 0 0 C ø Æ , < L Ö l ö
1 1 0 1 D CR æ - = M Ñ m ñ
1 1 1 0 E Å ß . > N Ü n ü
1 1 1 1 F å É / ? O § o à
Explanation of the GSM Alphabet Table

It is rather easy to read from the table. Let us say that we want the value
for the character "A" then remembering that it is a 7-bit alphabet (no bit
number 7 or bit number 7 is always set to zero), bits 6-4 =100 and bits
3-0 =0001. We, therefore, arrive at value 01000001=41hex.
Notice, at position 1B, we have a 1) symbol. This is not a character but
a reference to an extension table which we will not use here.
Nevertheless, information concerning the extension cable can be found
in GSM 03.38 along with other details about the GSM character table.
Example
To understand how the User Data, in our example, is packed into octets,
using the 7-bit alphabet, let us start translating the word TEST into
hexadecimal representation.
7 bits represents each letter in the word TEST. The individual bits are
denoted as follows:
T6, T5....T0
E6, E5....E0
And so on.
166
EN/LZT 123 922 R1A
SMS MESSAGES
The bits are packed as follows:
Bit numbers
7 6 5 4 3 2 1 0
E0 T6 T5 T4 T3 T2 T1 T0
S1 S0 E6 E5 E4 E3 E2 E1
T2 T1 T0 S6 S5 S4 S3 S2
0 0 0 0 T6 T5 T4 T3
Note! The last octet has to be filled with zero.

The hexadecimal representation of the word TEST is constructed via
the above-mentioned table and the default GSM alphabet.
Bit numbers
7 6 5 4 3 2 1 0 Hex
value
1 1 0 1 0 1 0 0 D4
1 1 1 0 0 0 1 0 E2
1 0 0 1 0 1 0 0 94
0 0 0 0 1 0 1 0 0A
The hexadecimal representation of TEST is: D4E2940A. Notice the

following two things:
1. The order of transmission is the same as described earlier.
2. The character "T" from the GSM table, is given as 54hex. This does not
match what we see above (D4hex). One cannot directly translate.
However, if one was sending 8-bit data and interpreting the data as an 8-bit
alphabet then a direct translation would be possible. The only drawback
would be that only 140 characters (octets) could be sent.
To translate the User Data example, the above-mentioned procedure has

to be performed but backwards. The Data is:
54747A0E4ACF416110945805B5CBF379F85C06
167
EN/LZT 123 922 R1A
Since this example is very long, only the first characters (the first 7
octets) will be considered in this manual.
Bit numbers
Hex 7 6 5 4 3 2 1 0
Value
54 0 1 0 1 0 1 0 0
74 0 1 1 1 0 1 0 0
7A 0 1 1 1 1 0 1 0
0E 0 0 0 0 1 1 1 0
4A 0 1 0 0 1 0 1 0
CF 1 1 0 0 1 1 1 1
41 0 1 0 0 0 0 0 1
Break this down into groups of 7 bits and translate then using the GSM
alphabet table. The result is:
1010100 = “T”
1101000 = “h”
1101001 = “i”
1110011 = “s”
0100000 = “ “ (space)
1101001 = “i”
1110011 =”s”
0100000 =” “ (space)
These are the first 8 characters in the message “This is a PDU message”.
The message is broken down into relevant fields and octets.
9.4 SMS-DELIVER
The SMS-DELIVER type of SMS is the message a mobile phone
receives from the Service Centre.
For the SMS-DELIVER messages, The same procedure is performed
for both SMS-Deliver and SMS-SUBMIT type messages.
Let us consider our previously constructed SMS-SUBMIT. It has been
sent from our mobile, passed through the Service Centre, and arrived at
its destination address. It will look like this:
07916407058099F9040B916407752743F60000990121017580001554
747A0E4ACF416110945805B5CBF379F85C06
168
EN/LZT 123 922 R1A
SMS MESSAGES
We can now break it down into the various fields.
9.4.1 The Service Centre Address
We should recognize the beginning portion:

07916407058099F9040B916407752743F60000990121017580001554
747A0E4ACF416110945805B5CBF379F85C06
The Service Centre Address originated the SMS-DELIVER PDU.
The number is: +46 705008999
9.4.2 TP-MTI and More Fields
The next octet contains nearly as many fields as the corresponding octet
in the SMS-SUBMIT PDU.
The fields are shown in the following table:
Bit number Description
0
Message type (TP-MTI)
1
2 More messages to Send (TP-MMS)
3 0
4 0
5 Status report indication (TP-SRI)
6 User data header indicator (TP-UDHI)
7 Reply Path (TP-RP)
Bits 3 and 4 are not used.
Message Type Indicator (TP-MTI)

This field specifies the type of SMS. See section 9.3.2, The Next Octet
(TP-MTI, TP-RD, TP-VPF, TP-SRR, TP-UDHI, TP-RP) on page 155
for more details.
More Messages to Send (TP-MMS)

This 1-bit field informs the receiver if there are any more messages
waiting at the Service Centre.
• If the value is 0, there are more messages waiting.
• If the value is 1, there are no messages waiting.
169
EN/LZT 123 922 R1A
Status Report Indication (TP-SRI)

This 1-bit field shows if a Status Report will be returned to the
originating mobile (the mobile station that submitted the SMS to the
Service Centre).
• If the parameter is 0, a Status Report will not be returned.
• If the value is 1, a Status Report will be returned.
This bit corresponds to TP-SRR (Status Report Request) as described in
the SMS-SUBMIT section. The Mobile station doing the sending must
be able toe of accept and interpret a Status Report.
User Data Header Indicator (TP-UDHI)

This field is the same as the corresponding field in the SMS-SUBMIT
PDU.
See section 9.3.2, The Next Octet (TP-MTI, TP-RD, TP-VPF, TP-SRR,
TP-UDHI, TP-RP) on page 155 or the GSM specification GSM 03.40
for more information concerning how the User Data Header is used.
Reply Path (TP-RP)

This field indicates whether if a reply is requested from the receiving
mobile station. It is the same as discussed in the SMS-SUBMIT PDU
section.
The Example
The value of this octet is 04.
7 0 (TP-RP)
6 0 (TP-UDH)
5 0 (TP-SRI)
4 0 0
3 0 0
2 1 (TP-MMS)
1 0
(TP-MTI)
0 0
• TP-MTI indicates that this is a PDU of an type SMS-DELIVER

type.
• TP-MMS indicates that there are no more messages waiting at the
Service Centre to be delivered.
• Bits 3 and 4 are set to 0.
170
EN/LZT 123 922 R1A
SMS MESSAGES
• TP-SRI is 0 which means that a status report is not to be returned to

the originating address.
• There will be no User Data Header since TP-UDHI is 0.
• TP-RP is 0 which means that no Reply Path is set.
Since many of these fields are identical or similar to those for the SMS-
SUBMIT PDU, you can read the section concerning SMS-SUBMIT or
the GSM Specification GSM 03.40 for more information.
9.4.3 The Originating Address (TP-OA)
This field is identical to the Destination Address field (TP-DA) as

described in the section pertaining to the SMS-SUBMIT PDU. The only
difference is that we are informed of the sender instead of receiving a
pertaining description to where the SMS will be delivered.
Let us decipher our example to see the originating mobile number.
07916407058099F9040B916407752743F60000990121017580001554
747A0E4ACF416110945805B5CBF379F85C06
The Originating Address is 0B916407752743F6
0B We expect the number to have 11 digits.
91 The number is an international number and it
uses the ISDN/telephone numbering plan.
6407752743F6 The number is +46 705772346.
9.4.4 The Protocol Identifier (TP-PID)
In our example of the SMS-DELIVER PDU, the Protocol Identifier is

shown below in bold:
07916407058099F9040B916407752743F60000990121017580001554
747A0E4ACF416110945805B5CBF379F85C06
This is identical to the TP-PID field described above in the SMS-
SUBMIT section. For additional information refer to GSM 03.40.
9.4.5 The Data Coding Scheme (TP-DCS)
In our example of SMS-DELIVER, the TP-DCS is displayed in bold:

07916407058099F9040B916407752743F60000990121017580001554
747A0E4ACF416110945805B5CBF379F85C06
The value is 00 which implies a classless SMS. According to the table
for TP-DCS (provided in the SMS-SUBMIT section), this means that
our data will use the default GSM alphabet and is intended for mobile-
171
EN/LZT 123 922 R1A
to-mobile communication. For more information concerning how to use

the GSM alphabet, see section 9.3.6, The Data Encoding Scheme (TP-
DCS) on page 161.
9.4.6 The Service Centre Time Stamp (TP-SCTS)
This field is specific to the SMS-DELIVER PDU. The Service Centre

Time Stamp in our example is shown in below:
07916407058099F9040B916407752743F60000990121017580001554
747A0E4ACF416110945805B5CBF379F85C06
When an SMS-SUBMIT PDU reaches the Service Centre, it is time
stamped by the Service Centre. The Time Stamp indicates the time in
which the Service Centre receives the SMS-SUBMIT PDU (that is the
time it was sent). Depending on how difficult it has been to reach the
destination mobile, the Time Stamp can vary from the actual time the
SMS was received. The limit of this variance is the chosen setting of the
Validity Period.
The Service Centre is integer represented. In our example, the Time
Stamp is:
99012101758000
The Time Stamp is described as follows:
Year Month Day Hour Minute Second Time

Zone
Octets 1 octet 1 octet 1 octet 1 octet 1 octet 1 octet 1 octet
Recall the order of transmission. Each pair of digits is reversed and

when rearranged, they give a date and time:
99 01 21 01 75 80 00 -pairing the digits.
99 10 12 10 57 08 00 -reversing the pairs.
Accordingly, the date is 991012. The time is 10:57 and 08 seconds.
The Time Zone field indicates the difference, expressed in quarters of
an hour, between local time and GMT. The 3rd bit of this octet
represents the indicator of the difference (0:positive and 1:negative).
The Time Zone code enables the receiver to calculate the equivalent
time in GMT from the rest of the Service Centre Time Stamp.
9.4.7 User Data Length (TP-UDL)
In our SMS-DELIVER PDU, TP-UDL is displayed in bold:

07916407058099F9040B916407752743F60000990121017580001554
747A0E4ACF416110945805B5CBF379F85C06
172
EN/LZT 123 922 R1A
SMS MESSAGES
See SMS-SUBMIT for more details.
9.4.8 The User Data (TP-UD)
The last field of the SMS-DELIVER is an important bit, the User Data:
07916407058099F9040B916407752743F60000990121017580001554
747A0E4ACF416110945805B5CBF379F85C06
9.4.9 Conclusions
The most useful PDU formats have been explained in this document.
For additional information, refer to the following GSM specifications:
• GSM TS 03.38 (V7.0.0) or subsequent versions.
• GSM TS 03.40 (V7.1.0) or subsequent versions.
In the foregoing, you will find detailed information about all SMS
PDUs.
9.5 Character Sets
9.5.1 The Implemented Character Sets for GM 32
The GM 32 supports several character sets. The module interprets the

received character codes depending upon which character set has been
selected with the command AT+CSCS. The following character sets are
supported:
• The International Reference Alphabet (IRA) character set according
to the ITU-T T.50. Default character set for the module. The
character range is 0 – 127.
• The GSM default character set according to GSM 03.38. The
character range is 0-127.
• The Latin 1 character set according to ISO 8859-1. The character
range is 0 – 255.
• The Ericsson character set that is identical to the GSM default
character set in the character range 0 – 127. This character set also
contains a second copy of the GSM default character set in the range
128 – 255.
7-bit characters are sent in the TE – module interface as 8-bit characters
with the most significant bit set to zero (0).
Note! The GSM character hexadecimal number 00 should not be used in order
to obtain the “commercial” at- character (@). Character code 00 will be
interpreted as an end of line in the AT protocol. Instead, use
hexadecimal number 80 in the Ericsson character set.
173
EN/LZT 123 922 R1A
9.5.2 The Table of Character Sets
The following table illustrates how the module for each character set
interprets the characters. Every string character sent to the module via
AT commands is internally converted into a corresponding GSM
character. Characters from the IRA and Latin 1 sets are converted to
GSM characters according to GSM 07.05. Deleted characters are shown
as light gray fields.
Example! The module will convert the hexadecimal number 13 to Γ, if you have
selected the GSM default character set with the command +CSCS. If,
however, you have chosen IRA, it will be deleted.
With the Ericsson character set, the GSM character 11 hexadecimal can
be sent to the module as character 91 hexadecimal (11 + 80).
Dec Hex IRA GSM ISO 8859-1 Ericsson
000 00 @ (invalid) @ (invalid)
001 01 £ £
002 02 $ $
003 03 ¥ ¥
004 04 è è
005 05 é é
006 06 ù ù
007 07 ì ì
008 08 ò ò
009 09 Ç Ç
010 0A LF LF LF LF
011 0B Ø Ø
012 0C ø ø
013 0D CR CR CR CR
014 0E Å Å
015 0F å å
016 10 D D
017 11 – –
018 12 F F
019 13 G G
020 14 L L
021 15 W W
022 16 P P
174
EN/LZT 123 922 R1A
SMS MESSAGES
023 17 Y Y
024 18 S S
025 19 Q Q
026 1A X X
027 1B 1) 1)
028 1C Æ Æ
029 1D æ æ
030 1E ß ß
031 1F É É
032 20 SP (space) SP (space) SP (space) SP (space)

033 21 ! ! ! !
034 22 " " " "
035 23 # (IRV) # # #
036 24 $ (IRV) ¤ $ ¤
037 25 % % % %
038 26 & & & &
039 27 ’ (apostrophe) ’ (apostrophe) ’ (apostrophe) ’ (apostrophe)

040 28 ( ( ( (
041 29 ) ) ) )
042 2A * * * *
043 2B + + + +
044 2C , (comma) , (comma) , (comma) , (comma)

045 2D - (hyphen - (hyphen - (hyphen - (hyphen
minus) minus) minus) minus)
046 2E . (full stop) . (full stop) . (full stop) . (full stop)

047 2F / / / /
048 30 0 (zero) 0 (zero) 0 (zero) 0 (zero)

049 31 1 1 1 1
050 32 2 2 2 2
051 33 3 3 3
052 34 4 4 4 4
053 35 5 5 5 5
054 36 6 6 6 6
055 37 7 7 7 7
175
EN/LZT 123 922 R1A
056 38 8 8 8 8
057 39 9 9 9 9
058 3A : (colon) : (colon) : (colon) : (colon)

059 3B ; (semicolon) ; (semicolon) ; (semicolon) ; (semicolon)
060 3C < < < <
061 3D = = = =
062 3E > > > >
063 3F ? ? ? ?
064 40 @ ¡ (inv excl mark) @ ¡ (inv excl mark)

065 41 A A A A
066 42 B B B B
067 43 C C C C
068 44 D D D D
069 45 E E E E
070 46 F F F F
071 47 G G G G
072 48 H H H H
073 49 I I I I
074 4A J J J J
075 4B K K K K
076 4C L L L L
077 4D M M M M
078 4E N N N N
079 4F O O O O
080 50 P P P P
081 51 Q Q Q Q
082 52 R R R R
083 53 S S S S
084 54 T T T T
085 55 U U U U
086 56 V V V V
087 57 W W W W
088 58 X X X X
176
EN/LZT 123 922 R1A
SMS MESSAGES
089 59 Y Y Y Y
090 5A Z Z Z Z
091 5B Ä Ä
092 5C Ö Ö
093 5D Ñ Ñ
094 5E Ü Ü
095 5F _ (underscore) § _ §
(underscore)
096 60 ¿ ¿
097 61 a a a a
098 62 b b b b
099 63 c c c c
100 64 d d d d
101 65 e e e e
102 66 f f f f
103 67 g g g g
104 68 h h h h
105 69 i i i i
206 6A j j j j
107 6B k k k k
108 6C l l l l
109 6D m m m m
110 6E n n n n
111 6F o o o o
112 70 p p p p
113 71 q q q q
114 72 r r r r
115 73 s s s s
116 74 t t t t
117 75 u u u u
118 76 v v v v
119 77 w w w w
120 78 x x x x
121 79 y y y y
177
EN/LZT 123 922 R1A
122 7A z z z z
123 7B ä ä
124 7C ö ö
125 7D ñ ñ
126 7E ü ü
127 7F à à
128 80 @
129 81 £
130 82 $
131 83 ¥
132 84 è
133 85 é
134 86 ù
135 87 ì
136 88 ò
137 89 Ç
138 8A LF
139 8B Ø
140 8C ø
141 8D CR
142 8E Å
143 8F å
144 90 D
145 91 –
146 92 F
147 93 G
148 94 L
149 95 W
150 96 P
151 97 Y
152 98 S
153 99 Q
154 9A X
178
EN/LZT 123 922 R1A
SMS MESSAGES
155 9B 1)
156 9C Æ
157 9D æ
158 9E ß
159 9F É
160 A0 SP (space)
161 A1 ¡ (inv excl !
mark)
162 A2 "
163 A3 £ #
164 A4 ¤ ¤
165 A5 ¥ %
166 A6 &
167 A7 § ’ (apostrophe)
168 A8 (
169 A9 )
170 AA *
171 AB +
172 AC , (comma)
173 AD - (hyphen
minus)
174 AE . (full stop)

175 AF /
176 B0 0
177 B1 1
178 B2 2
179 B3 3
180 B4 4
181 B5 5
182 B6 6
183 B7 7
184 B8 8
185 B9 9
186 BA : (colon)
179
EN/LZT 123 922 R1A
187 BB ; (semicolon)
188 BC <
189 BD =
190 BE >
191 BF ¿ ?
192 C0 A ¡ (inv excl mark)

193 C1 A A
194 C2 A B
195 C3 A C
196 C4 Ä D
197 C5 Å E
198 C6 Æ F
199 C7 Ç G
200 C8 E H
201 C9 E I
202 CA E J
203 CB E K
204 CC I L
205 CD I M
206 CE I N
207 CF I O
208 D0 P
209 D1 Ñ Q
219 D2 O R
211 D3 O S
212 D4 O T
213 D5 O U
214 D6 Ö V
215 D7 W
216 D8 Ø X
217 D9 U Y
218 DA U Z
219 DB U Ä
180
EN/LZT 123 922 R1A
SMS MESSAGES
220 DC Ü Ö
221 DD Y Ñ
221 DE Ü
223 DF ß §
224 E0 à ¿
225 E1 a a
226 E2 a b
227 E3 a c
228 E4 ä d
229 E5 å e
230 E6 æ f
231 E7 Ç g
232 E8 è h
233 E9 é i
234 EA e j
235 EB e k
236 EC ì l
237 ED i m
238 EE i n
239 EF i o
240 F0 p
241 F1 ñ q
242 F2 ò r
243 F3 o s
244 F4 o t
245 F5 o u
246 F6 ö v
247 F7 w
248 F8 ø x
249 F9 ù y
250 FA u z
251 FB u ä
181
EN/LZT 123 922 R1A
252 FC ü ö
253 FD y ñ
254 FE ü
255 FF y às
9.6 The AT Commands for Sending an SMS (PDU and Text mode)
9.6.1 AT+CSMS (Select Message Service)
Description Syntax Possible responses
Selects the message service AT+CSMS= +CSMS: <mt>,<mo>,<bm>

<service>. <service>
Indicates supported AT+CSMS? +CSMS: <service>,<mt>,<mo>,<bm>

message types along with
the current service setting.
Indicates the current AT+CSMS=? +CSMS: (list of supported <service>)

parameters.
+CSMS:(0)
This command selects the message service (<service>). It returns the

type of messages supported by the ME, that is: <mt> for mobile-
terminated messages, <mo> for mobile-originated messages, and <bm>
for broadcast-type messages.
Parameter Value Description
<service>
0 GSM 03.40 and 03.41 specific.

(Compatible with GAM 07.05
Phase 2).
<mt>
0 Mobile-terminated messages
not supported.
1 Mobile-terminated messages
supported.
<mo>
0 Mobile-originated messages
not supported.
182
EN/LZT 123 922 R1A
SMS MESSAGES
1 Mobile-originated messages
supported.
<bm>
0 Broadcast messages not

supported.
1 Broadcast messages
supported.
9.6.2 AT+CPMS (Preferred SMS Message Storage)
Selects the preferred AT+CPMS= +CPMS: <used1>,<total1>,<used2>,

message storage. <mem1>[,<mem2> <total2>,<used3>,<total3>
[,<mem3>]]
Reads the current AT+CPMS? +CPMS:

settings <mem1>,<used1>,<total1>,
<mem2>,<used2>,<total2>,
<mem3>,<used3>,<total3>.
Indicates the AT+CPMS=? +CPMS: (list of supported <mem1>), (list of

supported storages in supported <mem2>), (list of supported
<mem1>, <mem3>)
<mem2>, and
<mem3>. +CPMS:("ME","SM"),("ME","SM"),("ME","SM")
This set command selects the preferred memory storages <mem1>,

<mem2>, and <mem3> to be used for reading, writing, and so on. Area
<mem1> is the memory from which messages are read and deleted.
Area <mem2> is the memory in which writing and sending operations
are directed. Area <mem3> is the memory in which a received SMS is
referred to for storage.
<mem1> String type Memory from which messages are read

and deleted (see also the AT commands
+CMGL (List Messages), +CMGR (Read
Messages, and +CMGD (Delete
Message)
"ME" ME message storage.
"SM" SIM message storage.
<mem2> String type Memory to which writing and sending

operations are directed (see also the AT
commands +CMSS (Send Messages from
Storage), and +CMGW (Write Message to
Memory).
183
EN/LZT 123 922 R1A
<mem3> String type Memory to which received SMSs are

directed for storage (unless forwarded
directly to TE). Received CNMs are always
stored in "BM" (or some manufacturer-
specific storage) unless directly
forwarded to TE.
"SIM" SIM message storage.
<used1>, <used2>,
<used3>
Integer type Total number of messages currently in

<mem1>,<mem2>, and <mem3>,
respectively.
<total1>, <total2>,
<total3>
Integer type Total number of message locations in

<mem1>,<mem2>, and <mem3>,
respectively.
9.6.3 AT+CMGF (Message Format)
Selects the preferred AT+CMGF=<mode>

message storage. <CR>
Indicates the current AT+CMGF?<CR> +CMGF: <mode>

setting.
Indicates the AT+CMGF=?<CR> +CMGF: (list of supported <mode>)

supported parameters.
+CMGF:(0,1)
This command defines the message format to be used when an SMS is

transferred through the TE – module interface (that is between the host
and the module). <mode> indicates the format of messages used with
send, list, read, and write commands. It also indicates the format of
unsolicited result codes. <mode> can either be PDU mode (entire TP
data units used) or text mode (headers and body of the messages given
as separate parameters).
The test command returns supported modes as a compound value.
<mode>
0 PDU mode
1 Text mode
184
EN/LZT 123 922 R1A
SMS MESSAGES
9.6.4 AT+CSCA (Service Center Address)
Sets service centre AT+CSCA= OK

address. <sca>[,<tosca>]
Reads the current AT+CSCA? +CSCA: <sca>,<tosca>

setting.
Indicates whether the AT+CSCA=? +CSCA: (list of supported <tosca>),

command is
supported. +CSCA:(129,145,161,128-255)
This command updates the SMSC (Short Message Service Center)

address through which the mobile-originated SMSs are transmitted. In
the text mode, setting is used by send (+CMGS) and write (+CMGW)
commands. In the PDU mode, setting is used by the same commands,
but only when the length of the SMSC address coded into <pdu>
parameter equals zero. Note that a “+” in front of the number in <sca>
takes precedence over the <tosca> parameter. A number starting with
“+” will therefore always be treated as an international number. See also
the AT command +CMGS.
<sca>
String type GSM 04.11 RP SC address. Address-Value

field in string format; BCD numbers (or GSM
default alphabet characters) are
converted to characters of the currently
selected TE character set.
<tosca>
Integer type GSM 04.11 RP SC address. Type of Address

octet in integer format.
129 ISDN / telephony numbering plan, national

/ international unknown.
Default if no "+" in sca
145 ISDN / telephony numbering plan,

international number.
Default if "+" in sca.
161 ISDN / telephony numbering plan, national

number.
128-255 Other values refer GSM 04.08 section

10.5.4.7.
185
EN/LZT 123 922 R1A
9.6.5 AT+CSCB (Select Cell Broadcast Message Type)
Selects CBM types. AT+CSCB=[<mode> OK

[,<mids>]]
Reads the current AT+CSCB? +CSCB: <mode>,<mids>

setting.
Indicates the AT+CSCB=? +CSCB: (list of supported <mode>)

supported <mode>s.
+CSCB:(0)
This command sets the types of Cell Broadcast Messages (CBM) to be

received by the ME.
<mode>
0 Message types in <mids> and

<dcss> are accepted.
<mid>
String type All different possible

combinations of CBM message
identifiers, for example "0, 1, 5-
7".
Refer to <mid> in GSM 03.41
CBM Message Identifier in
integer format.
9.6.6 AT+CSAS (Save SMS Settings)
Saves settings. AT+CSAS OK

[=<profile>]
Indicates available AT+CSAS=? +CSAS: (list of supported <profile>)

profiles.
+CSAS:(0-2)
This command saves active message service settings to a non-volatile

memory. A module can contain several profiles of settings. Settings
specified with the AT commands +CSCA and +CSCB are saved. Some
settings are not supported by the storage (for example, SIM SMS
parameters), and they, therefore, cannot be saved.
<profile>
0-2 The manufacturer- specific profile

number where settings are to be stored.
186
EN/LZT 123 922 R1A
SMS MESSAGES
9.6.7 AT+CRES (Restore SMS Settings)
Restores settings. AT+CRES OK

[=<profile>]
Indicates available AT+CRES=? +CRES: (list of supported <profile>)

profiles.
+CRES: (0-2)
This command restores message service settings from a non-volatile

memory to an active memory. A module can contain several profiles of
settings. Settings specified with the commands +CSCA, +CSCB, and
+CSCB will be restored. Some settings may not be supported by the
storage (for example, SIM SMS parameters), and they, therefore cannot
be restored.
<profile>
0-2 The manufacturer- specific profile

number where settings are to be stored.
9.6.8 AT+CMGD (Delete Message)
Deletes message from AT+CMGD= OK

the preferred <index>
memory.
Indicates whether the AT+CMGD=?<CR>

command is
supported.
This command deletes a message from the preferred message storage

<mem1> at the location <index>. If deleting fails, the final result code
+CMS ERROR: <err> is returned. The test command displays the valid
memory locations.
<index> Same definition as in AT+CMGL, see

page 190.
187
EN/LZT 123 922 R1A
9.7 AT Commands PDU Mode
9.7.1 AT+CNMI (New Message Indications to TE)
Sets a new AT+CNMI= OK

message indication [<mode>
to the TE. [,<mt>[,<bm>[,<ds>
]]]]
Indicates current AT+CNMI? +CNMI: <mode>,<mt>,<bm>,<ds>

parameters.
Indicates supported AT+CNMI=? +CNMI: (list of supported <mode>), (list of

parameters supported <mt>, (list of supported <bm>),
(list of supported <ds>),
+CNMI:(3),(0-3),(0,2),(0-2)
This command selects the procedure for indicating how new messages
from the network to the TE (the host) are received, when the TE is
active. If the TE is inactive, messages should be processed as specified
in GSM 03.38.
The <mode> parameter controls the processing of unsolicited result
codes specified by +CNMI, and <bm> sets the result-code indication
routing for CBMs.
<mode>
3 Unsolicited result codes are forwarded directly

to the TE.
<mt>
0 No SMS-DELIVER (messages to ME) indications

are routed to the TE.
No class, Class 0, class 1, and class 3 use
<mem3> as preferred storage. Class 2
messages will be stored in the SIM. If this is not
possible, the MS will send an error message
accordingly to GSM 03.38.
1 If SMS-DELIVER is stored in the module, an

indication of the memory location is routed to
the TE using the unsolicited result code:
+CMTI: <mem>,<index>.
2 Class 0, class 1, and class 3 SMS-DELIVERs are

routed directly to the TE using the unsolicited
result code:
+CMT: [<alpha>],<length><CR><LF><pdu>
(PDU mode enabled).
3 Class 3 SMS-DELIVERs are routed directly to the

TE using the unsolicited result codes +CMT:
<length><CR><LF><pdu>. Messages of other
data coding schemes result in indication as
defined in <mt>=1.
<bm>
188
EN/LZT 123 922 R1A
SMS MESSAGES
0 No CBM indications are routed to the TE.
2 CBM is routed directly to the TE using the

unsolicited result code:
+CBM:<length><CR><LF><pdu>. New CBMs
are not stored in CBM memory.
<ds>
0 No SMS-STATUS-REPORTs are routed to the TE.

SMS-STATUS-REPORT is stored in the ME.
1 SMS-STATUS-REPORTs are routed to the TE using

unsolicited result code: +CDS: < length> < CR>
< LF> < pdu> (PDU mode enabled). SMS-
STATUS-REPORT is not stored in the ME.

unsolicited result code: +CDSI: < mem><index>
(PDU mode enabled). SMS-STATUS-REPORT is
stored in the ME.
Unsolicited Result Codes:

• +CMT: <length><CR><LF><pdu>
• +CMTI: <mem>,<index>
This is an indication of the memory location that is routed to the TE.
It occurs when a message has been received and SMS-DELIVER is
stored into the module.
• +CBM: <length><CR><LF><pdu>
• +CDS: <length><CR><LF><pdu>
• +CDSI: <mem><index>
<length>
Integer type The length of the actual TP data unit in

octets. The RP layer SMSC address octets
are not counted in the length.
<pdu>
For SMS: GSM 04.11 SC address followed

by GSM 03.40 TPDU in hexadecimal
format: The ME converts each octet of TP
data unit into a two-IRA-character-long
hexadecimal number.
For CBS: GSM 03.41 TPDU in a hexadecimal
format.
<mem>
189
EN/LZT 123 922 R1A
<index>
Integer type Value in the range of location numbers

that is supported by the associated
memory.
9.7.2 AT+CMGL (List Messages)
Returns messages from AT+CMGL[=<stat>] +CMGL: <index>,<stat>,[<alpha>],<length>

the preferred storage (<CR><LF><pdu>
to the TE in PDU format. +CMGL: <index>,<stat>,[<alpha>],<length>
<CR><LF><pdu>[...]]
Indicates supported AT+CMGL=? +CMGL: (list of supported <stat>)

parameters
+CMGL:(0-3)
This command returns messages with the status value <stat> from the
message storage <mem1>. Entire data units <pdu> will be returned. If
the status of the message is “received unread”, the status in the storage
will change to “received read”. If listing fails, the final result code
+CMS ERROR: <err> is returned.
<stat> String type Indicates the status of messages in

memory.
0 Received unread message (new

message.
1 Received read message.
2 Stored unsent message (only

applicable to SMS).
3 Stored sent message (only

applicable to SMS).
<index>
Integer type Value in the range of location

numbers supported by the
associated memory.
<alpha>
String type Manufacturer-specific. Should be

left empty but not omitted.
190
EN/LZT 123 922 R1A
SMS MESSAGES
<length>
Integer type The length of the actual TP data

unit in octets. The RP layer SMSC
address octets are not counted in
the length.
<pdu>
Integer type For SMS: GSM 04.11 SC address

followed by GSM 03.40 TPDU in
hexadecimal format: The ME
converts each octet of TP data unit
into a two-IRA-character-long
hexadecimal number.
For CBS: GSM 03.41 TPDU in a
hexadecimal format.
9.7.3 AT+CMGR (Read Message)
Returns messages from AT+CMGR=<index> +CMGR: <stat>[,<alpha>],<length><CR><LF>

the preferred storage <pdu>
to the TE.
Indicates whether if AT+CMGR=? OK

the command is
supported.
This command returns a message with the location value <index> from
message storage <mem1> to TE. The status of the message and entire
message data unit <pdu> is returned. If the status of the message is
“received unread”, the status in the storage changes to “received read”.
If reading fails, the final result code +CMS ERROR: <err> is returned.
<stat>
0, 1, 2, 3 Same definition as AT+CMGL, see

page 190
<index> Same definition as AT+CMGL
<alpha> Same definition as AT+CMGL
<length> Same definition as AT+CMGL
<pdu> Same definition as AT+CMGL
191
EN/LZT 123 922 R1A
9.7.4 AT+CMGS (Send Message)
Sends messages of size AT+CMGS=<length> +CMGS: <mr>[,<ackpdu>]

<length>. PDU is given
<ctrl-Z/ESC>
Indicates whether the AT+CMGS=?<CR> OK

command is supported.
This command sends messages from the TE (host) to the network

(SMS-SUBMIT). The message reference value <mr> is returned to the
TE if the message is successfully delivered.The module sends a four-
character sequence: <CR><LF><greater_than><space> (IRA 13, 10,
62, 32) after the command line is terminated with <CR>. Then, the PDU
can be issued from the TE (host) in one line.
When the length octet of the SMSC address (given in the <pdu>) equals
zero, the stored SMSC address (which is set with the command
+CSCA) is used.
The end of the PDU is indicated by <Ctrl-Z> (IRA 26). Otherwise,
sending can be cancelled by using the <Esc> character (IRA 27).
<mr>
Integer type Integer TP Message-Reference

according to GSM 03.40.
<ackpdu>
Integer type GSM 03.40 RP-User-Data

element of RP-ACK PDU. The
format is the same as the format
for <pdu>, but without the GSM
04.11 SC address field. The
parameter must be written
between double quotes like a
normal type parameter.
<length> Same definition as AT+CMGL.
192
EN/LZT 123 922 R1A
SMS MESSAGES
9.7.5 AT+CMSS (Send Message from Storage)
Sends messages from AT+CMSS=<index> +CMSS: <mr>

the storage.
Indicates whether the AT+CMSS=? OK

command is
supported.
This command sends a message with the location value <index> from
the message storage <mem2> to the network (SMS-SUBMIT). The
message reference value <mr> is returned to the TE (the host) if the
message is successfully delivered.
<index>
Integer type Value in the range of location

of numbers supported by the
associated memory.
<mr>
Integer type TP Message-Reference in

integer format according to
GSM 03.40.
9.7.6 AT+CMGW (Write Message to Memory)
Writes message to AT+CMGW= <length> +CMGW: <index>

memory <mem2>. [,<stat>]
PDU is given <ctrl-Z/ESC>
Indicates whether AT+CMGW=?<CR> OK

the command is
supported.
This command stores messages (either SMS-DELIVER or SMS-

SUBMIT) in memory <mem2>. The memory location <index> of the
stored message is returned. By default, the message status will be set to
“stored unsent” but the <stat> parameter will permit other status values
to be given. The PDU is entered similarly as specified in command
AT+CMGS.
193
EN/LZT 123 922 R1A
If writing fails, the final result code +CMS ERROR: <err> is returned.
<stat>
2 Stored unsent message.
<index> Same definition as AT+CMG, see

page 190.
<length> Same definition as AT+CMGL.
<pdu> Same definition as AT+CMGL.
9.7.7 AT+CMGC (Send Command)
Description Syntax Possible Responses
Send command AT+CMGC=<length><CR>< if PDU mode (+CMGF=0) and sending

message. pdu><ctrl-Z/ESC> successful:
+CMGC: <mr>[,<ackpdu>]
Indicates whether AT+CMGC=? OK

the commands is
supported.
This command sends a message from the TE to the network (SMS-

COMMAND). The entering of PDU is done similarly as specified in
command Send Message +CMGS. The message reference value <mr>
is returned to the TE upon successful message delivery. Optionally,
(when +CSMS <service> value is 1 and network supports) <ackpdu> is
returned. Values can be used to identify a message pursuant to the
unsolicited delivery status report result code. If sending fails in a
network or due to an ME error, final result code +CMS ERROR: <err>
is returned. This command should be abortable.
<length> Same definition as AT+CMGL,

see page 190.
<pdu> Same definition as AT+CMGL.
<mr>
Integer type GSM 03.40 TP-Message-

Reference.
<ackpdu>
String type GSM 03.40 RP-User-Data

element of RP-ACK PDU; format
is the same as for <pdu> in the
case of SMS, but without GSM
04.11 SCA address field and
parameter.
194
EN/LZT 123 922 R1A
SMS MESSAGES
9.8 AT Commands Text Mode
9.8.1 AT+CSMP (Set Text Mode Parameters)
Sets the text AT+CSMP= OK

mode [<fo>[,<vp>[,<pi
parameters. d>[,<dcs>]]]]
Reads the current AT+CSMP? +CSMP:<fo>,<vp>,<pid>,<dcs>

setting.
Indicates whether AT+CSMP=? +CSMP: (List of supported <fo>),

the command is (list of supported <vp>), (list of
supported. supported <pid>), (list of
supported <dcs>)
+CSMP:(0-255),(0-143,144-167,168-
196,197-255),(0-255),(0-255)
This command selects values for additional parameters that are

necessary when SM is sent to the network or placed in storage when text
format message mode is selected. It is possible to set the validity period
starting from when the SM is received by the SMSC (<vp> is in range
0-255). The <pid> parameter identifies the higher protocol being used.
It also indicates interworking with a certain type of telematic service.
The <dcs> determines the way the information is encoded as in GSM
03.38.
<fo>
0-255 Depending on the command or result code: first

octet of GSM 03.40 SMS-DELIVER, SMS-SUBMIT
(default 17),SMS-STATUS-REPORT, or SMS-
COMMAND (default 2) in integer format.
<vp>
0-143 (TP-VP+1) x 5 minutes

(i.e 5 minutes intervals up to 12 hours)
144-167 12 hours + ((TP_VP-143) x 30 minutes)
168-196 (TP-VP-166) x 1 day
197-255 (TP-VP-192) x 1 week
<pid>
0-255 Protocol Identifier in integer format. Default value

= 0. According to 07.05 section 9.2.3.9.
<dcs>
0-255 Data coding scheme. See GSM 03.48.

UCS2 and compressed text are not supported.
195
EN/LZT 123 922 R1A
9.8.2 AT+CSDH (Show Text Mode Parameters)
Sets the show text AT+CSDH= OK

mode. [<show>]
Reads the current AT+CSDH? +CSDH:<show>

setting.
Indicates whether AT+CSDH=? +CSDH: (List of supported <show>),

the command is
supported. +CSDH:(0)
This command controls whether detailed header information is shown

in text mode result codes.The test command returns supported values as
a compound value.
<show>
0 Do not show header values defined in

commands +CSCA and +CSMP
(<sca>,<tosca>,<fo>,<vp>,<pid> and <dcs>) nor
<length>, <toda> or <tooa> in +CMT, +CMGL,
+CMGR result codes for SMS-DELIVERs and SMS-
SUBMIT in text mode.
Do not show <pid>, <mn>, <da>, <toda>,
<length> or <cdata> for SMS-COMMAND in
+CMGR result code.
9.8.3 AT+CNMI (New Message Indication to TE)
Sets new AT+CNMI= OK

message [<mode>[,<mt>
indication to the [,<bm>[,<ds>]]]]
TE
Indicates the AT+CNMI? +CNMI: <mode>,<mt>,<bm>,<ds>

current setting.
Indicates whether AT+CNMI=? +CNMI: (list of supported

the command is <mode>),(list of supported
supported. <mt>),(list of supported <bm>),(list
of supported <ds>)
+CNMI: (3),(0-3),(0,2),(0-2)
This command selects the procedure for how to indicate the receipt of
new messages from the network to the TE when the TE is active, that is,
the DTR signal is ON. If the TE is inactive (that is the DTR signal is
OFF), the receipt of messages should be processed as specified in GSM
03.38.
196
EN/LZT 123 922 R1A
SMS MESSAGES
If the command fails and the error is related to the mobile equipment or
the network, return final result code CMS ERROR: <err>. For the
<err>-codes, see 1.3.2, +CMS ERROR (Message Service Failure Result
Code) on page 60.
<mode>
3 Forward unsolicited result codes directly to the TE.

The module-TE link specific inband technique
used to embed result codes and data when the
module is in on-line data mode.
<mt>
0 No SMS-DELIVER indications are routed to the TE.

Messages are stored in the module.
No class, Class 0, class 1 and class 3 use <mem3>
as preferred storage. Class 2 messages shall be
stored in the SIM. If this is not possible the MS shall
send an error message accordingly to GSM 03.38.
1 If SMS-DELIVER is stored into the ME, indication of

the memory location is routed to the TE using
+CMTI: <mem>,<index>
2 Class 0, class 1, and class 3 SMS-DELIVERs are

routed directly to the TE using the unsolicited
result code:
+CMT:<oa>, [<alpha>, <scts>, <CR><LF><data>
(Text Mode enabled).
3 Class 3 SMS-DELIVERs are routed directly to the TE

using unsolicited result codes:
+CMT<oa>, [<alpha>, <scts>, <CR><LF><data>
(Text Mode enabled).
<bm>
0 Store message to "BM" (or some manufacturer-

specific memory). No CBM indications are routed
to the TE.
2 New CBMs are routed directly to the TE using

+CBM: <sn>,<mid>,<dcs>,<page>,<pages><CR>
<LF><data> (Text mode enabled)
<ds>
0 No SMS-STATUS-REPORTs are routed to the TE.

+CDS: <fo>,<mr>,[<ra>],[<tora>],<scts>,<dt>,<st>
(Text mode enabled).
The SMS-STATUS-REPORT is not stored in the ME.

+CDSI: < mem><index> (Text mode enabled).
The SMS-STATUS-REPORT is stored in the ME.
197
EN/LZT 123 922 R1A
Unsolicited Result Codes:

• +CMT:<oa>, [<alpha>, <scts>, <CR><LF><data> (Text Mode
enabled).
This is a short message that is routed directly to the TE using
unsolicited result code +CMT. For information concerning
parameter values, see 9.8.5, AT+CMGR (Read Message) on page
203.
• +CMTI: <mem>,<index>
When a message has been received and SMS-DELIVER is stored in
the module there is an indication of the memory location where the
message is located.
• +CBM:<sn>,<mid>,<dcs>,<page>,<pages><CR><LF><data>
This is a Cell Broadcast Message. Received SMSs are routed
directly to the TE using unsolicited result code +CBM. For
information concerning parameter values, see 9.8.4, AT+CMGL
(List Messages) on page 199.
• +CDS: <fo>,<mr>,[<ra>],[<tora>],<scts>,<dt>,<st>
This is an SMS STATUS REPORT. The TE is indicated by the
means of an unsolicited result code. For information concerning
parameter values, see 9.8.4, AT+CMGL (List Messages) on page
199.
• +CDSI: <mem><index>
<mem>
<index>

supported by the associated memory.
198
EN/LZT 123 922 R1A
SMS MESSAGES
9.8.4 AT+CMGL (List Messages)
Lists AT+CMGL= If text mode (+CMGF=1), command

messages. [<stat>] successful and SMS-SUBMITs and SMS-
DELIVERs:
+CMGL: <index1>,<stat>,<oa/
da>,[<alpha>],[<scts>]<CR><LF><data>[<C
R><LF>
+CMGL:
<index2>,<stat>,<oa/
da>,[<alpha>],[<scts>]<CR><LF><data>[…]]
If text mode (+CMGF=1), command
successful and SMS-STATUS-REPORT:
+CMGL:
<index1>,<stat>,<fo>,<mr>,[<ra>],[<tora>],<s
cts>,<dt>,<st>[<CR><LF>
+CMGL:
<index2>,<stat>,<fo>,<mr>,[<ra>],[<tora>],<s
cts>,<dt>,<st>[…]]
successful and SMS-COMMANDs:
+CMGL:
<index>,<stat>,<fo>,<ct>[<CR><LF>
+CMGL:
<index>,<stat>,<fo>,<ct>[…]]
successful and CBM storage:
+CMGL:
<index>,<stat>,<sn>,<mid>,<page>,<pages
>,<CR><LF><data>[<CR><LF>
+CMGL:
<index>,<stat>,<sn>,<mid>,<page>,<pages
><CR><LF><data>[…]]
Reads the AT+CMGL? +CMGL:<stat>

current
setting.
Indicates AT+CMGL=? +CMGL: (List of supported <stat>),

whether the
command is +CMGL:(0-4)
supported.
This command returns messages with the status value <stat> from the
message storage <mem1> to the TE. If the status of the message is
“received unread”, the status in the storage will change to “received
read”. If listing fails, the final result code +CMS ERROR: <err> is
returned.
<index>

supported by <mem1>.
<stat> Integer type Indicates the status of messages in the

memory.
0 Received unread message (new message).
199
EN/LZT 123 922 R1A
2 Stored unsent message (only applicable to

SMS).
3 Stored sent messages (only applicable to

SMS).
4 All messages (only applicable to the +CMGL

command).
<alpha>
String type Manufacturer- specific. Should be left empty

but not omitted, that is, commas will mark the
place where it should be. The character set
used should be the one selected with
command Select TE Character Set, +CSCS.
<scts>
String type GSM 03.40 TP-Service-Centre-Time-Stamp in

time-string format (refer to <dt>).
<tora>
GSM 04.11 TP-Recipient-Address Type of

Address octet in integer format.
200
EN/LZT 123 922 R1A
SMS MESSAGES
<data> The entered text should be formatted as

follows:
• if <dcs> (set with +CSMP) indicates that the
GSM 03.38 default alphabet is used and,
further, <fo> indicates that the GSM 03.40
TP-User-Data-Header-Indication is not set:
– if TE character set other than "HEX"
(refer command Select TE
Character Set +CSCS in TS 07.07):
The ME converts the entered text
into the GSM alphabet according to
the rules of Annex A; backspace
can be used to delete the last
character and carriage returns can
be used (previously mentioned that
four character sequences will be
sent to the TE after every carriage
return is entered by the user).
– if TE character set is "HEX": the
entered text should consist of two
IRA character long hexadecimal
numbers which the ME converts to 7-
bit characters of the GSM alphabet
(for example 17 (IRA 49 and 55) will
be converted to character Π (GSM
23))
• if <dcs> indicates that the 8-bit or UCS2
data encoding scheme is used or <fo>
indicates that GSM 03.40 TP-User-Data-
Header-Indication is set: the entered text
should consist of two IRA character long
hexadecimal numbers which the ME
converts into an 8-bit octet (for example,
two characters 2A (IRA 50 and 65) will be
converted into an octet with an integer
value of 42)
• sending can be cancelled by giving <ESC>
character (IRA 27).
• <ctrl-Z> (IRA 26) must be used to indicate
the end of the message body.
<fo> First octet of SMS-DELIVER in integer format.
First octet of SMS-SUBMIT in integer format.
First octet of SMS-STATUS-REPORT in integer

format.
First octet of SMS-COMMAND in integer

format.
<ra>
String type GSM 03.40 TP-Recipient-Address-Value field.

BCD (or GSM default alphabet) are
selected TE character set (refer to the
command +CSCS. Type of address given by
<tosca>).
<oa>
String type GSM 03.40 TP-Originating-Address Value in

string format; BCD numbers (or GSM default
alphabetical characters) are converted into
characters of the currently selected TE
character (refer to the command +CSCS).
201
EN/LZT 123 922 R1A
<da>
String type GSM 03.40 TP-Destination-Address Value in

character (refer command +CSCS).
<mr>
Integer type GSM 03.40 TP-Message-Reference.
<dt>
String type GSM 03.40 TP-Discharge-Time in string format

"yy/MM/dd,hh:mm:ss+-zz. The characters
indicate year, month, day, hour, minutes,
seconds, and time zone.
<st>
Integer type GSM 03.40 TP-Status.
<ct>
Integer type GSM 03.40 TP-Command-Type (default 0).
<sn>
Integer type GSM 03.41 CBM Serial Number.
<mid>
String type All different, possible combinations of CBM

message identifiers (refer to <mid>). Default is
empty string, for example, "0,1,5-7".
<mid> GSM 03.41 is the CBM Message
Identifier in integer format.
<page>
Integer type GSM 03.41CBM Page Parameter bits 4-7 in

integer format.
<pages>
Integer type GSM 03.41 CBM Page Parameter bits 0-3 in

integer format.
202
EN/LZT 123 922 R1A
SMS MESSAGES
9.8.5 AT+CMGR (Read Message)
Lists AT+CMGR= If text mode (+CMGF=1), command

message. [<index>] successful and SMS-DELIVER:
+CMGR:
<stat>,<oa>,[<alpha>],<scts>,
<CR><LF><data>
successful and SMS-SUBMIT:
+CMGR:
<stat>,<da>,[<alpha>]<CR><LF><data>
successful and SMS-STATUS-REPORT:
+CMGR:
<stat>,<fo>,<mr>,[<ra>],[<tora>],<scts>,<dt
>,<st>
successful and SMS-COMMAND:
+CMGR:
<stat>,<fo>,<ct>,<length><CR><LF><cdata
>]
successful and CBM storage:
+CMGR:
<stat>,<sn>,<mid>,<dcs>,<page>,<pages>
<CR><LF><data>
Indicates AT+CMGR=? +CMGR:(list of supported <index>)

whether the
command is
supported.
This command returns messages with location index <index> from

message storage <mem1> to the TE. If the status of the message is
“received unread”,the status in the storage will change to “received
read”. If the listing fails, the final result code +CMS ERROR: <err> is
returned.
<index>
Integer type The value in the range of location numbers

supported by <mem1>.
<stat>
Integer type Indicates the status of messages in memory.
0 Received unread message (new message).
2 Stored unsent message (only applicable to

SMS).
3 Stored sent messages (only applicable to

SMS).
<oa>
203
EN/LZT 123 922 R1A
String type GSM 03.40 TP-Originating-Address Value in

character (refer command +CSCS).
<da>

alphabet characters) are converted into
character (refer command +CSCS). Type of
address given by <toda>.
<tora>
String type GSM 04.11 TP-Recipient-Address Type-of-

Address octet in integer format.
<alpha>
String type Manufacturer-specific. Should be left empty

but not omitted, that is,
commas will mark the place where it should
be. The character set in use should be the
one selected with Select TE Character Set
+CSCS command.
<scts>

time-string format (refer <dt>).
<data> See command AT+CMGL on page 190.
<fo>
0 First octet of SMS-DELIVER in integer format.
1 First octet of SMS-SUBMIT in integer format.
2 First octet of SMS-STATUS-REPORT in integer

format.
3 First octet of SMS-COMMAND in integer

format.
<mr>
<ra>
String type GSM 03.40 TP-Recipient-Address-Value field.

BCD (or GSM default alphabet) are
selected TE character set (refer to the +CSCS
command).
<dt>
String type GSM 03.40 TP-Discharge-Time in string format

"yy/MM/dd,hh:mm:ss+-zz. The characters
indicate year, month, day, hour, minutes,
seconds, and time zone.
<st>
204
EN/LZT 123 922 R1A
SMS MESSAGES
Integer type GSM 03.40 TP-Status.
<ct>
Integer type GSM 03.40 TP-Command-Type (default 0).
<sn>
Integer type GSM 03.41 CBM Serial Number.
<mid>
String type All different, possible combinations of CBM

message identifiers (refer to <mid>) (default is
empty string); for example, "0,1,5-7".
<mid> GSM 03.41 CBM Message Identifier in

integer format.
<page>

integer format.
<pages>

integer format.
<dcs>
0-255 Data encoding scheme. See GSM 03.48.

UCS2 and compressed text are not
supported.
<sca>
String type GSM 04.11 RP SC address Address-Value field

in string format; BCD numbers (or GSM default
character set.
9.8.6 AT+CMGS (Send Message)
Sends Message. AT+CMGS= OK

<da>[,<toda>]
<CR> +CMGS: <mr>[,<scts>]
Text is entered
<ctrl-Z/ESC>
Indicates whether AT+CMGS=?

the commands is
supported.
When executing this command, the TE sends a message to the network

(SMS-SUBMIT). A message reference value <mr> is returned to the TE
if message delivery is successful. Optionally, (when the AT+CSMS
<service> value is 1 and the network supports) <scts> is returned.
205
EN/LZT 123 922 R1A
Values can be used to identify a message within the unsolicited delivery

status report result code. If sending fails, in a network or in the event of
an ME error, the final result code +CMS ERROR: <err> is returned.
This command should be abortable.
• Entered text (GSM 03.40 TP-Data-Unit) is sent to the address <da>
and all current settings (refer to Set Text Mode Parameters +CSMP
and Service Centre Address +CSCA) are used to construct the actual
PDU in the ME.
• The module will send a four character sequence:
<CR><LF><greater_than><space> (IRA 13, 10, 62, 32) after the
command line is terminated with <CR>. Then, the text can be
entered from the TE to the module.
• The DCD signal will be in an ON state while the text is entered.
• The echoing of entered characters back from the module is
controlled by V.25ter echo command E.
• Sending can be cancelled by providing <ESC> character (IRA 27).
• <ctrl-Z> (IRA 26) must be used to indicate the end of the message
body.
The entered text should be formatted as follows:
• If <dcs> (set with +CSMP) indicates that the GSM 03.38 default
alphabet is in use and <fo> indicates that the GSM 03.40 TP-User-
Data-Header-Indication is not set:
– If the TE character set other than “HEX” (refer to the Select
TE Character Set +CSCS command in TS 07.07): The module
converts the entered text into the GSM alphabet according to
the rules of Annex A. The backspace can be used to delete the
last character and carriage returns can be used (previously
mentioned four character sequences will be sent to the TE after
every carriage return entered by the user).
– If the TE character set is ”HEX”: the entered text should
consist of two IRA character long hexadecimal numbers which
the module converts into 7-bit characters of GSM alphabet (for
example. 17 (IRA 49 and 55) will be converted into character
P (GSM 23)).
• If the <dcs> indicates that an 8-bit or UCS2 data encoding scheme is
used or <fo> indicates that the GSM 03.40 TP-User-Data-Header-
Indication is set: the entered text should consist of two IRA character
long hexadecimal numbers which the ME converts into 8-bit octet
206
EN/LZT 123 922 R1A
SMS MESSAGES
(for example two characters 2A (IRA 50 and 65) will be converted

into an octet with integer value of 42).
<da>
String GSM 03.40 TP-Destination-Address. BCD numbers

type (or GSM default alphabetical characters) are
converted to characters of the currently selected
TE character (refer to command +CSCS). Type of
Address is provided by <toda>.
<toda>
String GSM 04.11 TP-Destination- Address Type of

type Address octet in integer format. When the first
character of <da> is +(IRA 43), default is 145,
otherwise, the default is 129.
<scts>
String GSM 03.40 TP-Service-Centre-Time-Stamp in time-

type string format (refer to <dt>).
<mr>
Integer GSM 03.40 TP-Message-Reference.

type
9.8.7 AT+CMSS (Send Message From Storage)
Sends from storage. AT+CMSS=<index>[ +CMSS: <mr>[,<scts>]

,<da>[,<toda>]]
Indicates whether the AT+CMSS=? OK

commands is
supported.
When this command is executed, the message storage <mem2> sends

the message with location value <index> to the network (SMS-
SUBMIT or SMS-COMMAND). The reference value <mr> is returned
to the TE if message delivery was successful. Optionally, (when the
+CSMS <service> value is 1 and the network supports), <scts> is
207
EN/LZT 123 922 R1A
returned. If sending fails in a network or an ME error occurs, the final

result code +CMS ERROR: <err> is returned. This command should be
abortable.
<index>
Integer The value in the range of location numbers

type supported by the associated memory.
<toda>

type (or GSM default alphabet characters) are
converted into characters of the currently
selected TE character (refer to the +CSCS
command). Type of address given by <toda>.
<toda>
String GSM 04.11 TP-Destination- Address Type of

type Address octet in integer format. When the first
otherwise, the default is 129.
<scts>
String GSM 03.40 TP-Service-Centre-Time-Stamp in time-

type string format (refer <dt>).
<mr>
Integer GSM 03.40 TP-Message-Reference.

type
9.8.8 AT+CMGW (Write Message To Memory)
Writes message AT+CMGW[=<oa/ +CMGW: <index>

to memory. da>[,<tooa/
toda>[,<stat>]]]<CR>
text is entered <ctrl-Z/
ESC>
Indicates whether AT+CMGW=? OK

the commands is
supported.
Execution of this command permits a message (either SMS-DELIVER

or SMS-SUBMIT) into the memory storage <mem2>. The memory
location <index> of the stored message is returned. By default, the
message status will be set to ’stored unsent’ but parameter <stat>
permits other status values to be given.The entering of text is done in a
manner similar to that specified in the Send Message +CMGS
command. If writing fails, the final result code +CMS ERROR: <err>
will be returned.
208
EN/LZT 123 922 R1A
SMS MESSAGES
Note! SMS-COMMANDs and SMS-STATUS-REPORTs cannot be stored in

text mode.
<stat>
Integer Indicates the status of messages in memory.

type
2 Stored unsent message (only applicable to SMS).
<oa>
String GSM 03.40 TP-Originating-Address. BCD numbers

converted to characters of the currently selected
TE character (refer to the +CSCS command).
Type of address is given by <tooa>.
<da>

converted into characters of the currently
selected TE character (refer to the +CSCS
command). Type of address is given by <toda>.
<tooa>
String GSM 04.11 TP-Originating-Address Type-of-

type Address octet in integer format (default refer to
<toda>).
<toda>
String GSM 04.11 TP-Destination- Address Type-of-

type Address octet in integer format. When first
otherwise default is 129.
<index>
Integer Value in the range of location numbers

type supported by the associated memory
9.8.9 AT+CMGC (Send command)
Sends command AT+CMGC=<fo>,<ct>[,< If Text mode (+CMGF=1)

message. pid>[,<mn>[,<da>[,<tod and sending successful:
a>]]]]<CR> text is +CMGC: <mr>[,<scts>]
entered<ctrl-Z/ESC>
Indicates whether AT+CMGC=? OK

the commands is
supported.
When this command is executed, the TE sends a command (SMS-

COMMAND) to the network.The entering of text is done in a similar
manner to that specified in the Send Message +CMGS command. The
format is fixed to be a sequence of two IRA character long hexadecimal
209
EN/LZT 123 922 R1A
numbers. The ME converts these into 8-bit octets (refer to +CMGS). A

message reference value,<mr>, is returned to the TE if message
delivery is successful. Optionally, (when the +CSMS <service> value
is 1 and the network supports) <scts> is returned. Values can be used to
identify a message within the unsolicited delivery status report result
code. If sending fails in a network or if an ME error occurs, the final
result code +CMS ERROR: <err> is returned. This command should be
abortable.
<fo>
0 First octet of SMS-DELIVER in integer format.
1 First octet of SMS_SUBMIT in integer format.
2 First octet of SMS-STATUS-REPORT in integer

format.
3 First octet of SMS-COMMAND in integer

format.
<ct>
Integer type GSM 03.40 TP-Command-Type (default 0.
<pid>
0-255 Protocol Identifier in integer format. Default

value = 0. According to 07.05 section 9.2.3.9.
<mn>
Integer type GSM 03.40 TP-Message-Number.
<da>

character (refer to the +CSCS command).
Type of address given by <toda>.
<toda>
String type GSM 04.11 TP-Destination- Address Type-of-

Address octet in integer format (when first
character of <da> is +(IRA 43) the default is
145, otherwise the default is 129.
<mr>
<scts>

time-string format (refer <dt>).
210
EN/LZT 123 922 R1A
SMS MESSAGES
9.9 Examples on How to Use the AT Commands
9.9.1 PDU and Text Mode
AT+CSMS (Select Message Service)

By this configuration you set up the module to support GSM SMS.
Sent AT Command Response Action/Description
AT+CSMS=0 Set GSM SMS.
+CSMS: 1,1,0 MT and MO supported,

CBM not supported.
OK
AT+CPMS (Select Preferred Message Storage)

By this configuration you select preferred memory storage. The total
messages currently and the total number of message locations for the
chosen message storage will be given as response.
AT+CPMS="SM","SM", "SM" Set SIM memory.
+CPMS: 3,20,3,20,3,20 Three messages in SIM, total number

of message locations is 20.
OK
AT+CPMS="ME","ME","ME" Set ME memory. Overwrites previous

setting.
+CPMS: 5,10,5,10,5,10 Five messages in ME, total number of

message locations is 20.
OK
AT+CMGF (Select Message Format)

With this command you define the message format that is used when an
SMS is transferred between the host and the module.
AT+CMGF=0 Select PDU mode
OK
9.9.2 PDU Mode
AT+CNMI (New Message Indication)

This command selects the procedure for indicating how new messages
from the network to the TE are received.
211
EN/LZT 123 922 R1A
In the example the MS is set so that an unsolicited SMS indication is

sent to the TE when a new SMS-DELIVER is received from the
network and then successfully stored in the <mem1> storage.
AT+CNMI=? Query new message unsolicited result

code modes.
+CNMI: (3),(0-3),(0,2), Note that indication of CDS is

(0-2) supported.
OK
AT+CNMI=3,1,2,1 Send SM indications to TE using +CMTI.

Forward unsolicited CBM result codes
directly to the TE and send SMS-STATUS-
REPORTs to the TE using unsolicited
result code: +CDS.
OK
AT+CNMI? Query current settings.
+CNMI: 3,1,2,1 Response according to set command.
The MS receives and stores incoming

SM.
+CMTI: "ME",3 New message received in index 3 of

<mem> storage.
The MS receives a CBM an routes it

directly to TE.
+CBM: 128 New CBM PDU of 128 byte received at

<128 byte PDU> TE.
AT+CMGL (List Message)

With this command you list the messages in the memory selected as
preferred.
AT+CMGL=0 List "Received Unread" messages
+CMGL: 1,0,,128 Message in index 1 and 2 of ME are

<…pdu…> received and unread. The length
(128 and 68) indicates the length of
+CMGL: 2,0,,68 the TPDU-part of the PDU. The length
<…pdu…> of the SMSC-part of the PDU is
OK excluded from the length.
AT+CMGL=1 List "Received Read" messages.
OK No messages are received and

read.
AT+CMGL=2 List "Stored Unsent" messages.
OK No messages are Stored and

unsent.
212
EN/LZT 123 922 R1A
SMS MESSAGES
AT+CMGL=3 List "Stored Sent" messages.
+CMGL: 1,3,,32 Message in index 1 of SM is stored

<…pdu…> and sent.
OK
AT+CMGL=4 List "ALL" messages.
+CMGL: 1,0,,128 Message in index 1 and 2 of ME are

<…pdu…> received and unread.
Message in index 1 of SM is stored
+CMGL: 2,0,,68 and sent.
<…pdu…>
+CMGL: 1,3,,32
<…pdu…>
OK
AT+CMGR (Read Message)

When using this command as shown below the status and entire
message data unit of the message with the location value 2 are returned,
AT+CMGR=2 Read message at index 2.
+CMGR: 0,,68 Message, received and unread.

<…pdu…> Status in storage is changed to
received and read.
OK
AT+CMGS (Send Message)

A message in PDU mode is sent from the command line.
AT+CMGS=128<CR> Write and send a message.
<CR><LF> The MS shall send a four character

sequence <CR><LF><greater_than>
<space> after command line is
terminated with <CR>; after that
PDU can be given from TE to MS.
<128 byte pdu>

<ctrl-z>
+CMGS: 10 Message reference 10 is returned

from the Service Center.
OK
213
EN/LZT 123 922 R1A
214
EN/LZT 123 922 R1A

Handling SMS

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Handling SMS

Hochgeladen von

Copyright:

Verfügbare Formate

9.

This chapter explains the SMS-related AT commands. SMS messages

9.1 About SMS

9.2 About the PDU

9.2.1 What is a PDU?

When we use a mobile phone, we usually enter a text message on the

9.2.2 The Transmission Order

Octets in a PDU are transmitted according to their order. Octets

A table using the binary representation is as follows:

There are a few different meanings given to the hexadecimal

9.3.1 The Service Centre Address (SCA)

Binary representation Field meaning

07 0 0 0 0 0 1 1 1 Address length- This octet

91 1 0 0 1 0 0 0 1 This is the type of Address

64 0 1 1 0 0 1 0 0 The digits 4 and 6

07 0 1 1 0 0 1 0 0 The digits 7 and 0

05 0 0 0 0 0 1 0 1 The digits 5 and 0

80 1 0 0 0 0 0 0 0 The digits 0 and 8

99 1 0 0 1 1 0 0 1 The digits 9 and 9

F9 1 1 1 1 1 0 0 1 The digit 9. Since there are an

Type of Address Octet

Bit number Bit value Description

7 1, always Fill bit

Bit number Bit value Description

001 International number

010 National number

011 Network specific number

6,5,4 100 Subscriber number

101 Alphanumeric, (coded according to GSM

110 Abbreviated number

111 Reserved for extension

0001 ISDN/telephone numbering plan

0011 Data numbering plan (X.121)

0100 Telex numbering plan

1010 ERMES numbering plan

1111 Reserved for extension

All other values are reserved

With this information, it will be possible to understand the SCA

2. If the telephone number contains an odd number of digits, add an F at the

3. Pair the numbers: 46 07 50 08 9F

4. Reverse the digits: 64 07 05 08 99 F9

Bit number Description

7 Reply Path (TP-RP)

6 User data header indicator (TR-UDH)

5 Status report request (TP-SRR)

2 Reject duplicates (TP-RD)

In the following subchapters, a description of the fields will be

Message Type Indicator (TP-MTI)

Bit 1 Bit 0 Direction SC-MS Direction MS-SC

0 0 SMS-DELIVER SMS-DELIVER REPORT

1 0 SMS-STATUS REPORT SMS-COMMAND

0 1 SMS-STATUS REPORT SMS-SUBMIT

In this document, only SMS-SUBMIT and SMS-DELIVER PDUs will

Reject Duplicates (TP-RD)

Validity Period Format (TP-VPF)

Bit 4 Bit 3 Description

0 0 No validity Period will be present.

1 0 Relative format used for the Validity Period.

0 1 Enhanced format used for the Validity Period.

1 1 Absolute format used for the Validity period.

Since relative format is typically sufficient, it is the only format

Status Report Request (TP-SRR)