Table of Contents
What are the AT commands?
What are the AT commands? AT commands are instructions used to control a modem. AT is the abbreviation of Attention. Every command line starts with “AT” or “at”. That’s why modem commands are called AT commands. Many of the commands that are used to control wired dial-up modems, such as ATD (Dial), ATA (Answer), ATH (Hook control) and ATO (Return to online data state), are also supported by GSM/GPRS modems and mobile phones. Besides this common AT command set, GSM/GPRS modems and mobile phones support an AT command set that is specific to the GSM technology, which includes SMS-related commands like AT+CMGS (Send SMS message), AT+CMSS (Send SMS message from storage), AT+CMGL (List SMS messages) and AT+CMGR (Read SMS messages).
Types of AT commands
There are two types of AT commands:
- Basic commands
- Extended commands.
Basic commands are AT commands that do not start with “+”. For example, D (Dial), A (Answer), H (Hook control) and O (Return to online data state) are basic commands.
Extended commands are AT commands that start with “+”. All GSM AT commands are extended commands. For example, +CMGS (Send SMS message), +CMSS (Send SMS message from storage), +CMGL (List SMS messages) and +CMGR (Read SMS messages) are extended commands
Type of Extended AT Commands:
Test Command
AT+<X>=?
The mobile equipment returns the list of parameters and value ranges set with the corresponding Write command or by internal processes
Read Command
AT+<X>?
This command returns the currently set value of the parameter or parameters.
Set Command
AT+<X>=<…>
This command sets the user-definable parameter values.
Execution Command
AT+<X>
The execution command reads non-variable parameters affected by internal processes in the GSM engine.
Some common AT commands:
| Command | Description |
| AT+CMGF | Select SMS message format |
| AT+CMGF=0 | PDU mode |
| AT+CMGF=1 | TEXT mode |
| ATA | answer an incoming call |
| ATH | disconnect the existing connection |
| ATDL | redial the last number |
| AT+CMGL | LIST SMS MESSAGES |
| AT+CMGS | SEND SMS MESSAGE |
| AT+CMGR | read the SMS |
| AT+CMGD | delete the SMS |
| AT+CMGW | WRITE SMS MESSAGE TO MEMORY |
| AT+CMSS | SEND SMS MESSAGE FROM STORAGE |
| AT+CMGC | SEND SMS COMMAND |
| AT+CNMI | NEW SMS MESSAGE INDICATIONS |
| AT+CPMS | PREFERRED SMS MESSAGE STORAGE |
| AT+CRES | RESTORE SMS SETTINGS |
| AT+CSAS | SAVE SMS SETTINGS |
| AT+CSCA | SMS SERVICE CENTER ADDRESS |
| AT+CSCB | SELECT CELL BROADCAST SMS MESSAGES |
| AT+CSDH | SHOW SMS TEXT MODE PARAMETERS |
| AT+CSMP | SET SMS TEXT MODE PARAMETERS |
| AT+CSMS | SELECT MESSAGE SERVICE |
SMS using Ericsson T68i
Introduction of SMS
Short Message Service (SMS) is a service available on most digital mobile phones (and other mobile devices, e.g. a Pocket PC, or occasionally even desktop computers) that permits the sending of short messages (also known as text messages) between mobile phones, other handheld devices and even landline telephones. Other uses of text messaging can be for ordering ring tones, wallpapers and entering competitions.
Technical details of SMS
Messages are sent via a store-and-forward mechanism to a Short Message Service Centre (SMSC), which will attempt to send the message to the recipient and possibly retry if the user is not reachable at a given moment. Message delivery is best effort, so there are no guarantees that a message will actually be delivered to its recipient and delay or complete loss of a message is not uncommon, particularly when sending between networks. Users may choose to request delivery reports, which can provide positive confirmation that the message has reached the intended recipient.
Transmission of the short messages between SMSC and phone can be done through different protocols such as SS7 within the standard GSM MAP framework or TCP/IP within the same standard.
Larger content (known as long SMS or concatenated SMS) can be sent segmented over multiple messages, in which case each message will start with a user data header (UDH) containing segmentation information. Since UDH is inside the payload, the number of characters per segment is lower: 153 for 7 bit encoding, 134 for 8 bit encoding and 67 for 16 bit encoding. The receiving phone is then responsible for reassembling the message and presenting it to the user as one long message. While the standard theoretically permits up to 255 segments, 6 to 8 segment messages are the practical maximum, and long messages are billed as equivalent to multiple SMS messages.
Some service providers offer the ability to send messages to land line telephones regardless of their capability of receiving text messages by automatically phoning the recipient and reading the message aloud using a speech synthesizer along with the number of the sender.
Today, SMS is also used for machine to machine communication. For instance, there is a LED display machine controlled by SMS, and some vehicle tracking companies like ESITrack use SMS for their data transport or telemetry needs.
The PDU format
There are two ways of sending and receiving SMS messages: by text mode and by PDU (protocol description unit) mode. The text mode (unavailable on some phones) is just an encoding of the bit stream represented by the PDU mode. Alphabets may differ and there are several encoding alternatives when displaying an SMS message. These are all set by the at-command AT+CSCS, when you read the message in a computer application. If you read the message on your phone, the phone will choose a proper encoding. An application capable of reading incoming SMS messages can thus use text mode or PDU mode. If text mode is used, the application is bound to (or limited by) the set of preset encoding options. In some cases, that’s just not good enough. If PDU mode is used, any encoding can be implemented.
Receiving a message in the PDU mode
| AT command | Meaning |
| +CNMI | New message indications |
| +CMGL | List messages |
| +CMGR | Read messages |
| +CNMA | New message acknowledgement |
The PDU string contains not only the message, but also a lot of meta-information about the sender, his SMS service center, the time stamp etc. It is all in the form of hexa-decimal octets or decimal semi-octets. The following string is an example received on a Ericsson T28 when sending the message containing “1” from any other mobile.
AT+CPMS=”ME”
AT+CMGL=0
AT+CMGR=1
AT+CMGD=1
| 07 | 91294355000001 | 240C912943450248880000607051815273020131 |
This octet sequence consists of three parts: An initial octet indicating the length of the SMSC information (“07”), the SMSC information itself (“91294355000001”), and the SMS_DELIVER part (specified by ETSI in GSM 03.40).
| 07 | Length of the SMSC information (in this case 7 octets) |
| 91 | 91 means international format of the phone number |
| 294355000001
|
Service center number(in decimal semi-octets). The phone number of this service center is “+923455000010”. |
| 24 | First octet of this SMS-DELIVER message. |
| 0C | Address-Length. Length of the sender number (0C hex = 12 dec) |
| 91 | Type-of-address of the sender number |
| 294345024888 | Sender number (+923454208488) |
| 00 | TP-PID. Protocol identifier. |
| 00 | TP-DCS Data coding scheme |
| 60705181527302 | TP-SCTS. Time stamp (semi-octets) |
| 01 | TP-UDL. User data length, length of message. The TP-DCS field indicated 7-bit data, so the length here is the number of septets (1). If the TP-DCS field were set to indicate 8-bit data or Unicode, the length would be the number of octets (9). |
| 31 | 31(HEX)=0011 0001(BIN)= 49(ASCII)
=> ‘1’ TP-UD. Message “1” , 8-bit octets representing 7-bit data. |
All the octets above are hexa-decimal 8-bit octets, except the Service center number, the sender number and the timestamp; they are decimal semi-octets. The message part in the end of the PDU string consists of hexa-decimal 8-bit octets, but these octets represent 7-bit data (see below).
The semi-octets are decimal, and e.g. the sender number is obtained by performing internal swapping within the semi-octets from “92 34 54 20 48 44” to “29 43 45 02 48 88”. The length of the phone number is even. Another example if sender number would be odd then the sender number is obtained by performing internal swapping within the semi-octets from “72 38 88 09 00 F1” to “27 83 88 90 00 1F”. The length of the phone number is odd, so a proper octet sequence cannot be formed by this number. This is the reason why the trailing F has been added. The time stamp, when parsed, equals “60705181527302”, where the 6 first characters represent date, the following 6 represents time, and the last two represents time-zone related to GMT.
| 60 70 51 | 06 07 15 | 15th July 2006 |
| 81 52 73 | 18 25 37 | 18hrs 25mins 37sec |
| 02 | Time Zone 02 | |
Interpreting 8-bit octets as 7-bit messages
This transformation is described in detail in GSM 03.38, and an example of the “high: temp” transformation is shown below. The transformation is based on the 7 bit default alphabet, but an application built on the PDU mode can use any character encoding.
In form of septets:
h 1101000
i 1101001
g 1100111
h 1101000
: 0111010
0100000
t 1110100
e 1100101
m 1101101
p 1110000
Coding 7-bit data (septets) into octets
The message “high: temp” consists of 10 characters, called septets when represented by 7 bits each. These septets need to be transformed into octets for the SMS transfer.
| h | i | G | h | : | ||||||||||
| 104 | 101 | 108 | 108 | 111 | ||||||||||
| 1101000 | 1101001 | 1100111 | 1101000 | 0111010 | ||||||||||
|
|
|
|
|
||||||||||
| t | e | m | ||||||||||||
| 104 | 101 | 108 | 108 | |||||||||||
| 0100000 | 1110100 | 1100101 | 1101101 | |||||||||||
|
|
|
|
The first septet (h) is turned into an octet by adding the rightmost bit of the second septet. This bit is inserted to the left which yields 1 + 1101000 = 11101000 (“E8”). The rightmost bit of the second character is then consumed, so the second character (septet) needs two bits (yellow) of the third character to make an 8bit octet. This process goes on and on yielding the following octets:
|
|
|
|
|
||||||||||
| E8 | F4 | 19 | AD | 03 | ||||||||||
|
|
|
|
|||||||||||
| D1 | CB | 6D | 38 |
Making octets:
11101000
11110100
00011001
10101101
00000011
11010001
11001011
01101101
00111000
1110 1000 E 8
1111 0100 F 4
0001 1001 1 9
1010 1101 A D
0000 0011 0 3
1101 0001 D 1
1100 1011 C B
0110 1101 6 D
0011 1000 3 8
E8F419AD03D1CB6D38 (high: temp)
923314489312
293341849321
Sending “high: temp” TO 923314489312
at+CMGF=0
at+CSMS=0
at+CMGS=23
0011000C912933418493210000AA0AE8F419AD03D1CB6D38
| Octet(s) | Description | |
| 00 | Length of SMSC information. Here the length is 0, which means that the SMSC stored in the phone should be used. Note: This octet is optional. On some phones this octet should be omitted! (Using the SMSC stored in phone is thus implicit) | |
| 11 | First octet of the SMS-SUBMIT message. | |
| 00 | TP-Message-Reference. The “00” value here lets the phone set the message reference number itself. | |
| 0C | Address-Length. Length of phone number (12) | |
| 91 | Type-of-Address. (91 indicates international format of the phone number). | |
| 293341849321 | The phone number in semi octets (923314489312). The length of the phone number is even (12). In other case if length would be odd e.g. 11 then a trailing F will be added, as if the phone number were “46708251358F”. | |
| 00 | TP-PID. Protocol identifier. | |
| 00 | TP-DCS. Data coding scheme. This message is coded according to the 7bit default alphabet. Having “04” instead of “00” here, would indicate that the TP-User-Data field of this message should be interpreted as 8bit rather than 7bit (used in e.g. smart messaging, OTA provisioning etc). | |
| AA | TP-Validity-Period. “AA” means 4 days. | |
| 0A | TP-User-Data-Length. Length of message. The TP-DCS field indicated 7-bit data, so the length here is the number of septets (10). If the TP-DCS field were set to 8-bit data or Unicode, the length would be the number of octets. | |
| E8F419AD03D1CB6D38 | TP-User-Data. These octets represent the message “high: temp”. How to do the transformation from 7bit septets into octets is shown |
First octet of the SMS-SUBMIT PDU
The first octet of the SMS-SUBMIT PDU has the following layout:
| Bit no | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| Name | TP-RP | TP-UDHI | TP-SRR | TP-VPF | TP-VPF | TP-RD | TP-MTI | TP-MTI |
where the fields have the following meaning:
| Fieldname | Meaning |
| TP-RP | Reply path. Parameter indicating that reply path exists. |
| TP-UDHI | User data header indicator. This bit is set to 1 if the User Data field starts with a header |
| TP-SRR | Status report request. This bit is set to 1 if a status report is requested |
| TP-VPF | Validity Period Format. Bit4 and Bit3 specify the TP-VP field according to this table: bit4 bit3 0 0 : TP-VP field not present 1 0 : TP-VP field present. Relative format (one octet) 0 1 : TP-VP field present. Enhanced format (7 octets) 1 1 : TP-VP field present. Absolute format (7 octets) |
| TP-RD | Reject duplicates. Parameter indicating whether or not the SC shall accept an SMS-SUBMIT for an SM still held in the SC which has the same TP-MR and the same TP-DA as a previously submitted SM from the same OA. |
| TP-MTI | Message type indicator. Bits no 1 and 0 are set to 0 and 1 respectively to indicate that this PDU is an SMS-SUBMIT |
Example
A first octet of “11” (hex) has the following meaning:
| Bit no | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| Name | TP-RP | TP-UDHI | TP-SRR | TP-VPF | TP-VPF | TP-RD | TP-MTI | TP-MTI |
| Value | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
The Type-of-Address octet
| Bit no | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| Name | Always set to 1 | Type-of-number | Numbering Plan Identification | |||||
Note that bit no 7 should always be set to 1.
Bits 6, 5 and 4 denote the Type-of-number e.g. 0 0 1 : International number.
Bits 3, 2, 1, 0 denote the Numbering-Plan-Identification e.g. ISDN/telephone numbering plan.
Sending a message in the PDU mode
| AT command | Meaning |
| +CMGS | Send message |
| +CMSS | Send message from storage |
| +CMGW | Write message to memory |
| +CMGD | Delete message |
| +CMGC | Send command |
| +CMMS | More messages to send |
The following example shows how to send the message “High: temp” in the PDU mode from a Nokia 6110.
AT+CMGF=0 //Set PDU mode AT+CSMS=0 //Check if modem supports SMS commands AT+CMGS=23 //Send message, 23 octets (excluding the two initial zeros)
>0011000C912903900493670000AA0AE8F419AD03D1CB6D38
There are 23 octets in this message (46 ‘characters’). The first octet (“00”) doesn’t count, it is only an indicator of the length of the SMSC information supplied (0).
For complete report, click here FYP report