Saturday, January 12, 2013

Validity Period (TP-VP)

This is the detail of previous post SMS-PDU

Validity Period (TP-VP)

Validity period specifies the time when SM expires. If SM is't delivered before that moment, it is discarded by SC. Validity-Period can be in three different format; Relative, Absolute and Enhanced.

Relative:

The TP-Validity-Period comprises 1 octet in integer representation, giving the length of the validity period, counted from when the SMS-SUBMIT is received by the SC. The representation of time is as follows:
TP-VP valueValidity period value
0 to 143(TP-VP + 1) * 5 minutes (i.e. 5 minutes intervals up to 12 hours)
144 to 16712 hours + ((TP-VP - 143) * 30 minutes)
168 to 196(TP-VP - 166) * 1 day
197 to 255(TP-VP - 192) * 1 week

Absolute

TP-VP field is 7 octets long, containing TP-SCTS formatted time when SM expires. See ETSI 03.40 for more information.

Protocol Identifier (TP-PID)

This is the explanation of previous post SMS-PDU


Protocol Identifier (TP-PID)

The TP-Protocol-Identifier parameter consists of one octet, and the bits in the octet are used as follows: The MS will interpret reserved or unsupported values as the value 00000000 but shall store them exactly as received. The SC may reject messages with a TP-Protocol-Identifier containing a reserved value or one which is not supported.

Bit 7 Bit 6 Usage
0 0 Assigns bits 0..5 as defined below
0 1 Assigns bits 0..5 as defined below
1 0 Reserved
1 1 Assigns bits 0..5 for SC specific use

In case where bits 7 and 6 both are 0:
Bit 5Description
0no interworking, but SME-to-SME protocol
1telematic interworking

In the case of telematic interworking, the following five bit patterns in bits 4..0 are used to indicate types of telematic devices:
Bits 4..0 Description
00000 implicit - device type is specific to this SC, or can be concluded on the basis of the address
00001 telex (or teletex reduced to telex format)
00010 group 3 telefax
00011group 4 telefax
00100voice telephone (i.e. conversion to speech)
00101ERMES (European Radio Messaging System)
00110National Paging System (known to the SC)
00111Videotex (T.100/T.101)
01000teletex, carrier unspecified
01001teletex, in PSPDN
01010teletex, in CSPDN
01011teletex, in analog PSTN
01100teletex, in digital ISDN
01101UCI (Universal Computer Interface, ETSI DE/PS 3 01-3)
01110..
..01111
(reserved, 2 combinations)
10000a message handling facility (known to the SC)
10001any public X.400-based message handling system
10010Internet Electronic Mail
10011..
..10111
(reserved, 5 combinations)
11000..
..11110
values specific to each SC, usage based on mutual agreement between the SME and the SC (7 combinations available for each SC)
11111A GSM mobile station. The SC converts the SM from the received TP-DCS to any data coding scheme supported by that MS (e.g. the default).

If bit 5 has value 1 in an SMS-SUBMIT PDU, it indicates that the SME is a telematic device of a type which is indicated in bits 4..0, and requests the SC to convert the SM into a form suited for that device type. If the destination network is ISDN, the SC must also select the proper service indicators for connecting to a device of that type.

If bit 5 has value 1 in an SMS-DELIVER PDU, it indicates that the SME is a telematic device of a type which is indicated in bits 4..0.

If bit 5 has value 0 in an SMS-DELIVER PDU, the value in bits 4..0 indicates the SM-AL protocol being used between the SME and the MS.

Note that for the straightforward case of simple MS-to-SC short message transfer the Protocol Identifier is set to the value 0.

In the case where bit 7 = 0, bit 6 = 1, bits 5..0 are used as defined below
Bits 5..0Description
000000Short Message Type 0
000001Replace Short Message Type 1
000010Replace Short Message Type 2
000011Replace Short Message Type 3
000100Replace Short Message Type 4
000101Replace Short Message Type 5
000110Replace Short Message Type 6
000111Replace Short Message Type 7
001000..011110Reserved
011111Return Call Message
100000..111100Reserved
111101ME Data download
111110ME De-personalization Short MEssage
111111SIM Data download

A short message type 0 indicates that the ME must acknowledge receipt of the short message but may discard its contents. The Replace Short Message feature is optional for the ME and the SIM but if implemented it shall be performed as descriped here. For MT short messages, on receipt of a short message from from the SC, the MS shall check to see if the associated Protocol Identifier contains a Replace Short Message Type code.

If such a code is present, the the MS will check the originating address and replace any existing stored message having the same Protocol Identifier code and originating address with the new short message and other parameter values. If there is no message to be replaced, the MS shall store the message in the normal way. The MS may also check the SC address as well as the Originating Address. However, in a network which has multiple SCs, it is possible for a Replace Message type for a SM to be sent via different SCs and so it is recommended that the SC address should not be checked by the MS unless the application specifically requires such a check. If a Replace Short Message Type code is not present then the MS will will store the message in the normal way. In MO short messages the SC reacts similarly but only the address of the originating MS or any other source is checked.

A Return Call Message indicates to the MS to inform the user that a call (e.g. a telephone call) can be established to the address specified within the TP-OA. The RP-OA contains the address of the SC as usual. The message content (if present) gives displayable information (e.g. the number of waiting voice messages). The message is handled in the same way as all other messages of the Replace Short Message Types. The ME De-personalization Short Message is an ME-specific message which instructs the ME to de-personalities the ME (see GSM 2.22). The TP-DCS shall be set to Uncompressed, Default Alphabet, and Message Class 1 (Me-specific), which corresponds to a bit coding og 00010001. The TP-UD field contains de-personalization information coded according to GSM 02.22. This information shall not be displayed by an ME which supports the scheme. The acknowledgement to this message is a SMS-DELIVER-REPORT for RP-ACK in ehich the TP-User-Data shall be coded according to GSM 02.22. SIM Data download is a facility whereby the ME must pass the short message in its entirety including all SMS elements contained in the SMS deliver to the SIM using the mechanism descriped in GSM 11.11. The DCS shall be set to 8 bit message class 2 (either bit coding 11110110 or 00010110). The entire user data field is available for SIM Data download.

ME Data download is facility whereby the ME shall process the short message in its entirety including all SMS elements contained in the SMS deliver to the ME. The DCS shall be set to message class 1. The entire user data field is available for ME data download.





First Octet of The SMS-Submit PDU

This is the detail of SMS-PDU

First octet of the SMS-SUBMIT PDU

The first octet of the SMS-SUBMIT PDU has the following layout:

Bit no76543210
NameTP-RPTP-UDHITP-SRRTP-VPFTP-VPFTP-RDTP-MTITP-MTI

where the fields have the following meaning:

FieldnameMeaning
TP-RPReply path. Parameter indicating that reply path exists.
TP-UDHIUser data header indicator. This bit is set to 1 if the User Data field starts with a header
TP-SRRStatus report request. This bit is set to 1 if a status report is requested
TP-VPFValidity 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-RDReject 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-MTIMessage 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 no76543210
NameTP-RPTP-UDHITP-SRRTP-VPFTP-VPFTP-RDTP-MTITP-MTI
Value00010001

SMS PDU

This is just a copy/replicate from former url http://dreamfabrics.com/sms/ which site has suspended, it's content was very useful for understanding pdu sms for programming. [note: Links below not updated yet, I'll try my best to update all of them].

SMS and the PDU format


Introduction

The SMS message, as specified by the Etsi organization (documents GSM 03.40 and GSM 03.38), can be up to 160 characters long, where each character is 7 bits according to the 7-bit default alphabet. Eight-bit messages (max 140 characters) are usually not viewable by the phones as text messages; instead they are used for data in e.g. smart messaging (images and ringing tones) and OTA provisioning of WAP settings. 16-bit messages (max 70 characters) are used for Unicode (UCS2) text messages, viewable by most phones. A 16-bit text message of class 0 will on some phones appear as a Flash SMS (aka blinking SMS or alert SMS).

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. The most common options are "PCCP437", "PCDN", "8859-1", "IRA" and "GSM". 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

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 what I received on a Nokia 6110 when sending the message containing "hellohello" from www.mtn.co.za.

07917283010010F5040BC87238880900F10000993092516195800AE8329BFD4697D9EC37

This octet sequence consists of three parts: An initial octet indicating the length of the SMSC information ("07"), the SMSC information itself ("917283010010F5"), and the SMS_DELIVER part (specified by ETSI in GSM 03.40).

Note: on some phones (e.g. Ericssson 888?) the first three (colored) parts are omitted when showing the message in PDU mode!


Octet(s) Description
07 Length of the SMSC information (in this case 7 octets)
91Type-of-address of the SMSC. (91 means international format of the phone number)
72 83 01 00 10 F5Service center number(in decimal semi-octets). The length of the phone number is odd (11), so a trailing F has been added to form proper octets. The phone number of this service center is "+27381000015". See below.
04First octet of this SMS-DELIVER message.
0BAddress-Length. Length of the sender number (0B hex = 11 dec)
C8Type-of-address of the sender number
72 38 88 09 00 F1Sender number (decimal semi-octets), with a trailing F
00 TP-PID. Protocol identifier.
00 TP-DCS Data coding scheme
99 30 92 51 61 95 80 TP-SCTS. Time stamp (semi-octets)
0A 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 (10). If the TP-DCS field were set to indicate 8-bit data or Unicode, the length would be the number of octets (9).
E8329BFD4697D9EC37 TP-UD. Message "hellohello" , 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 "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 "99 03 29 15 16 59 08", where the 6 first characters represent date, the following 6 represents time, and the last two represents time-zone related to GMT.

Interpreting 8-bit octets as 7-bit messages

This transformation is described in detail in GSM 03.38, and an example of the "hellohello" transformation is shown here. The transformation is based on the 7 bit default alphabet , but an application built on the PDU mode can use any character encoding.

Sending a message in the PDU mode

The following example shows how to send the message "hellohello" 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) &gt;0011000B916407281553F80000AA0AE8329BFD4697D9EC37<ctrl-z> </ctrl-z> 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). The PDU string consists of the following:

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.
0B Address-Length. Length of phone number (11)
91 Type-of-Address. (91 indicates international format of the phone number).
6407281553F8 The phone number in semi octets (46708251358). The length of the phone number is odd (11), therefore a trailing F has been added, as if the phone number were "46708251358F". Using the unknown format (i.e. the Type-of-Address 81 instead of 91) would yield the phone number octet sequence 7080523185 (0708251358). Note that this has the length 10 (A), which is even.
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. Note: This octet is optional, see bits 4 and 3 of the first octet
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.
E8329BFD4697D9EC37 TP-User-Data. These octets represent the message "hellohello". How to do the transformation from 7bit septets into octets is shown here