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
will 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.
In case where bits 7 and 6 both are 0:
|Bit 7||Bit 6||Usage|
|0||0||Assigns bits 0..5 as defined below|
|0||1||Assigns bits 0..5 as defined below|
|1||1||Assigns bits 0..5 for SC specific use|
In the case of telematic interworking, the following five bit patterns
in bits 4..0 are used to indicate types of telematic devices:
|0||no interworking, but SME-to-SME protocol|
|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|
|00011||group 4 telefax|
|00100||voice telephone (i.e. conversion to speech)|
|00101||ERMES (European Radio Messaging System)|
|00110||National Paging System (known to the SC)|
|01000||teletex, carrier unspecified|
|01001||teletex, in PSPDN|
|01010||teletex, in CSPDN|
|01011||teletex, in analog PSTN|
|01100||teletex, in digital ISDN|
|01101||UCI (Universal Computer Interface, ETSI DE/PS 3 01-3)
|(reserved, 2 combinations)|
|10000||a message handling facility (known to the SC)|
|10001||any public X.400-based message handling system|
|10010||Internet Electronic Mail|
|(reserved, 5 combinations)|
|values specific to each SC, usage based on
mutual agreement between the SME and the SC (7 combinations available for each
|11111||A 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
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
|000000||Short Message Type 0|
|000001||Replace Short Message Type 1|
|000010||Replace Short Message Type 2|
|000011||Replace Short Message Type 3|
|000100||Replace Short Message Type 4|
|000101||Replace Short Message Type 5|
|000110||Replace Short Message Type 6|
|000111||Replace Short Message Type 7|
|011111||Return Call Message|
|111101||ME Data download|
|111110||ME De-personalization Short MEssage|
|111111||SIM 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 will be performed as described here.
For MT short messages, on receipt of a short message from from the SC,
the MS will check to see if the associated Protocol Identifier contains
a Replace Short Message Type code.
If such a code is present, 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 will 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, 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-personalize the ME (see GSM 2.22). The TP-DCS
will 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
will not be displayed by an ME which supports the scheme. The acknowledgment
to this message is an SMS-DELIVER-REPORT for RP-ACK in which the TP-User-Data
will 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 described in GSM 11.11. The DCS will 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 a facility whereby the ME will process the short
message in its entirety including all SMS elements contained in the SMS
deliver to the ME. The DCS will be set to message class 1. The entire
user data field is available for ME data download.