|
|
|
|
 |
SMS Data Dissectedhow to
interpret TPU information read from a GSM cellphone
|
|
Connecting to a mobile and issuing a few AT commands is straightforward. But exchanging SMS data requires familiarity with the composition of the Protocol Data Unit (PDU), that is required by -or given in response to- most SMS-specific AT commands. And be prepared to come across minor changes, depending on the manufacturer’s implementation of the standards.
A PDU looks like a long hexadecimal string, representing the number of the network operator’s SMS central (Service Centre Address, SCA) chained to the whole packet used in the SMS transport layer (often referred as Transport Protocol Data Unit, TPDU). The latter includes many sub-fields in addition to the message text itself. Most data is packed to save bits.
A nice way to get a copy of both sent and received PDUs is to send yourself a simple SMS, then connect the mobile to PC and read the message from its memory using the AT+CMGL command.
The following example shows the PDU for the message HALLO WORLD, sent from the number ++39 347 3820955 at 04h:55m:16s PM of the 13th of January 2002. The mobile used was an Ericsson T10s and the Service Centre number was ++39 349 2000509:
|
01 |
80 |
11 |
00 |
0A |
81 |
43 |
37 |
28 |
90 |
55 |
00 |
00 |
A7 |
0B |
C8 |
20 |
93 |
F9 |
04 |
5D |
9F |
52 |
26 |
11 |
|
SCA |
ID |
MR |
DA |
PID |
DCS |
VP |
UDL |
USER DATA |
||||||||||||||||
|
SMS-SUBMIT TPDU |
||||||||||||||||||||||||
|
PDU RETURNED BY THE AT+CMGL COMMAND |
||||||||||||||||||||||||
|
07 |
91 |
93 |
43 |
29 |
00 |
50 |
90 |
04 |
0C |
91 |
93 |
43 |
37 |
28 |
90 |
55 |
00 |
00 |
20 |
10 |
31 |
61 |
55 |
61 |
04 |
0B |
C8 |
20 |
93 |
F9 |
04 |
5D |
9F |
52 |
26 |
11 |
|
SCA |
ID |
OA |
PID |
DCS |
SCTS |
UDL |
UD |
|||||||||||||||||||||||||||||
|
SMS‑DELIVER TPDU |
||||||||||||||||||||||||||||||||||||
|
PDU RETURNED BY THE AT+CMGL COMMAND |
||||||||||||||||||||||||||||||||||||
The first packet is the SMS-SUBMIT, used for sending a message; the second is the SMS-DELIVER packet, for receiving. The subfields are detailed in the following table:
|
SCA |
Service Centre Address |
Network operator’s Service Centre number. Not required by some mobiles. An hex value of 00 or 01‑80 means “unknown”: the mobile will use the default number stored in mobile’s settings. |
1 or 2 to 12 bytes |
|
ID |
TPDU type identifier |
SMS-DELIVER or SMS-SUBMIT identifiers and flags (e.g. request of a status report or presence of VP field) . |
1 byte |
|
MR |
Message Reference |
Progressive number (0 to 255). |
1 byte |
|
OA or DA |
Originating or Destination Address |
Sender’s or destination phone number. Note that a different number encoding from that of SCA is used. |
2 to 12 bytes |
|
PID |
Protocol Identifier |
Nature of data transported (FAX, voice, etc.), used by the Service Centre for a better routing. |
1 byte |
|
DCS |
Data Coding Scheme |
Format of the data transported (7 or 8 bits, alphabet, etc.) and where to store it (Mobile memory, SIM module, or for immediate display). |
1 byte |
|
SCTS |
Service Centre Time Stamp |
Year, month, day, hour, minute, seconds and time difference with respect to GMT. |
7 bytes |
|
VP |
Validity Period |
How long the network operator service centre will hold the message, if undelivered (A7=24 hours). |
0, 1, or 7 bytes |
|
UDL |
User Data Length |
Length of data, prior to encoding (e.g. 11 7-bit characters fit into 10 bytes). |
1 byte |
|
UD |
User Data |
Our message data, “HALLO WORLD” |
0-140 bytes |
Phone numbers start with the number’s length, intended as field length in bytes for the service centre (SCA), and digits for the remaining numbers (DA, OA). The second byte specifies the numbering plan: 80 = unknown, 81 = national number, 91 = international number. Then follow the digits, swapped in pairs and each occupying a nibble. This is how the number ++39 349 200-059 is encoded:
|
1st byte (length) |
2nd byte (format) |
3rd byte |
4th byte |
5th byte |
6th byte |
7th byte |
8th byte |
|||||||||||||||
|
0 |
7 |
9 |
1 |
9 |
3 |
4 |
3 |
2 |
9 |
0 |
0 |
5 |
0 |
F |
9 |
|||||||
If the length is odd, the unused nibble (semi-octet in ETSI language) is padded with $F.
Some mobiles don’t require the SCA, or accept 00 or 01-80 as valid values for the service centre address: in that case the mobile will use the its default service centre number.
An SMS message, according to ETSI specification, can be up to 140 bytes long (octets in ETSI terminology). The usual GSM alphabet requires only 7 bits per character (a septet), allowing for the packing of up to 140 * 8 / 7 = 160 characters.
The following is an example of how a 7-bit data is packed between successive bytes.
The 7-bit binary encoding of the string “GSM” is: G = 1000111, S = 1010011, M = 1001101
Let G0 be the bit 0 of letter G, G1 be the bit 1 of letter G, and so on: then the PDU will pack data as:
|
First Byte |
Second Byte |
Third Byte |
|||||||||||||||||||||||
|
S0 |
G6 |
G5 |
G4 |
G3 |
G2 |
G1 |
G0 |
M1 |
M0 |
S6 |
S5 |
S4 |
S3 |
S2 |
S1 |
zp |
zp |
zp |
M6 |
M5 |
M4 |
M3 |
M2 |
||
|
1 |
1 |
0 |
0 |
0 |
1 |
1 |
1 |
0 |
1 |
1 |
0 |
1 |
0 |
0 |
1 |
0 |
0 |
0 |
1 |
0 |
0 |
1 |
1 |
||
Note how the last three spare places are padded with zeroes (zp).
Other SMS-GSM designs on this site:
|
|
|
