Content for  TS 23.040  Word version:  18.0.0

The TP-Message-Type-Indicator is a 2-bit field, located within bits no 0 and 1 of the first octet of all PDUs which can be given the following values:

  bit1  bit0  Message type
  
  0     0     SMS-DELIVER (in the direction SC to MS)
  0     0     SMS-DELIVER REPORT (in the direction MS to SC)
  1     0     SMS-STATUS-REPORT (in the direction SC to MS)
  1     0     SMS-COMMAND (in the direction MS to SC)
  0     1     SMS-SUBMIT (in the direction MS to SC)
  0     1     SMS-SUBMIT-REPORT (in the direction SC to MS)
  1     1     Reserved

If an MS receives a TPDU with a "Reserved" value in the TP-MTI it shall process the message as if it were an "SMS-DELIVER" but store the message exactly as received.

The TP-More-Messages-to-Send is a 1-bit field, located within bit no 2 of the first octet of SMS-DELIVER and SMS-STATUS-REPORT, and to be given the following values:

  bit2
  
  0  More messages are waiting for the MS in this SC
  1  No more messages are waiting for the MS in this SC

The TP-Validity-Period-Format is a 2-bit field, located within bit no 3 and 4 of the first octet of SMS-SUBMIT, and to be given the following values:

  bit4  bit3
  
  0     0     TP-VP field not present
  1     0     TP-VP field present - relative format
  0     1     TP-VP field present - enhanced format
  1     1     TP-VP field present - absolute format

Any unsupported value may be rejected by the SC by returning the "TP-VPF not supported" TP-FCS value in the SMS Submit Report for RP-Error.

The TP-Status-Report-Indication is a 1-bit field, located within bit no. 5 of the first octet of SMS-DELIVER, and to be given the following values:

  bit5
  
  0  A status report shall not be returned to the SME
  1  A status report shall be returned to the SME

The TP-Status-Report-Request is a 1-bit field, located within bit no. 5 of the first octet of SMS-SUBMIT and SMS-COMMAND, and to be given the following values:

  bit5
  
  0  A status report is not requested
  1  A status report is requested

The TP-Message-Reference field gives an integer representation of a reference number of the SMS-SUBMIT or SMS-COMMAND submitted to the SC by the MS. The MS increments TP-Message-Reference by 1 for each SMS-SUBMIT or SMS-COMMAND being submitted. The value to be used for each SMS-SUBMIT is obtained by reading the Last-Used-TP-MR value from the SMS Status data field in the (U)SIM (see GSM TS 51.011 and TS 31.102) and incrementing this value by 1. After each SMS-SUBMIT has been submitted to the network, the Last-Used-TP-MR value in the (U)SIM is updated with the TP-MR that was used in the SMS-SUBMIT operation. The reference number may possess values in the range 0 to 255. The value in the TP-MR assigned by the MS is the same value which is received at the SC. In the case where no response or an RP-ERROR with an appropriate cause value (see TS 24.011) is received in response to an SMS-SUBMIT, then the MS shall automatically repeat the SMS-SUBMIT but must use the same TP-MR value and set the TP-RD bit to 1 (see 9.2.3.25). The number of times the MS automatically repeats the SMS-SUBMIT shall be in the range 1 to 3 but the precise number is an implementation matter. The automatic repeat mechanism should be capable of being disabled through MMI. If all automatic attempts fail (or in the case of no automatic attempts the first attempt fails), the user shall be informed. The failed message shall be stored in the mobile in such a way that the user can request a retransmission using the same TP-MR value, without the need to re-enter any information. Such storage need only be provided for a single failed message, i.e. the one most recently attempted. The SC should discard an SMS-SUBMIT which has the TP-RD bit set to a 1 and which has the same TP-MR value as the previous SMS-SUBMIT received from the same originating address. In the case of a discarded SMS-SUBMIT, the SC should respond with an RP-ERROR, in which case the RP-ERROR shall include a SMS-SUBMIT-REPORT with TP-FCS indicating "SM Rejected - Duplicate SM". In some cases, for backward compatibility with earlier phases and versions of this specification, the SC may be configured to respond with an RP-ACK. The SMS-STATUS-REPORT also contains a TP-Message-Reference field. The value sent to the MS shall be the same as the TP-Message-Reference value generated by the MS in the earlier SMS-SUBMIT or SMS-COMMAND to which the status report relates.

The TP-Originating-Address field is formatted according to the formatting rules of address fields. The first '#' encountered in TP-OA indicates where the address for SMSC routing purposes is terminated. Additional '*'s or '#'s can be present in the following digits, and all these digits including the first '#' are subaddress digits.

The TP-Destination-Address field is formatted according to the formatting rules of address fields. The first '#' encountered in TP-DA indicates where the address for SMSC routing purposes is terminated. Additional '*'s or '#'s can be present in the following digits, and all these digits including the first '#' are subaddress digits.

The TP-Protocol-Identifier parameter serves the purposes indicated in clause 3.2.3. It consists of one octet, and the bits in the octet are used as follows: The MS shall interpret reserved, obsolete, 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.

  bits  usage
  7  6
  
  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 the case where bit 7 = 0 and bit 6 = 0, bit 5 indicates telematic interworking: value = 0: value = 1: In the case of telematic interworking, the following five bit patterns in bits 4..0 are used to indicate different types of telematic devices: 4.. .0 00000 00001 00010 00011 00100 00101 00110 00111 01000 01001 01010 01011 01100 01101 01110..01111 10000 10001 10010 10011..10111 11000..11110 11111 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 identifies 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 5 .. . .0 000000 000001 000010 000011 000100 000101 000110 000111 001000 001001..011101 011110 011111 100000..111011 111100 111101 111110 111111 A short message type 0 indicates that the ME must acknowledge receipt of the short message but shall discard its contents. This means that

• the MS shall be able to receive the type 0 short message irrespective of whether there is memory available in the (U)SIM or ME or not,
• the MS shall not indicate the receipt of the type 0 short message to the user,
• the short message shall neither be stored in the (U)SIM nor ME.

The Replace Short Message feature is optional for the ME and the (U)SIM but if implemented it shall be performed as described here. For MT short messages, on receipt of a short message 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, then the MS shall 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 shall 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. The Device Triggering Short Message feature is optional for the MS, but if implemented it shall be performed as described here. For MT short messages, on receipt of a short message from the SC, the MS can check to see if the associated Protocol Identifier contains a Device Triggering Short Message code. If such a code is present, then the MS shall interpret the short message as a device triggering short message. The value contained in the Application Port Addressing information element identifies the application to receive the trigger. MO short messages with a Protocol Identifier containing a Device Triggering Short Message code are not supported and shall be discarded by the SC. 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 a ME-specific message which instructs the ME to de-personalities the ME (see TS 22.022). The TP-DCS shall be set to Uncompressed, Default Alphabet, and Message Class 1 (ME-specific), which corresponds to a bit coding of 00010001. The TP-UD field contains de-personalization information coded according to TS 22.022. 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 which the TP-User-Data shall be coded according to TS 22.022. (U)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 (U)SIM using the mechanism described in GSM TS 51.011 and TS 31.102. The DCS shall be set to message class 2. The entire user data field is available for (U)SIM Data download. If the DCS is not set to message class 2 then the message shall be handled in the normal way by the ME. However it has to be noted that MEs based on releases of this specification earlier than REL-5 may allow only 8 bit message class 2 with bit coding 11110110 or 00010110 for (U)SIM Data download. ME Data download is a 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 should normally be set to message class 1. If the DCS is set to message class 1 and no application in the ME exists, which is able to process the short message, the ME may discard the short message. The entire user data field is available for ME data download. The TPDU parameters required for the SMS-DELIVER should be passed transparently by all involved SCs, so no TPDU parameter in the entire short message is modified, other than the changes required to convert an SMS-SUBMIT into an SMS-DELIVER. ANSI-136 R-DATA is a facility whereby the ME must pass the short message in its entirety, including all elements contained in the SMS DELIVER, to the (U)SIM using the mechanism described in GSM TS 11.14 [16] and TS 31.102. The DCS shall be set to message class 2. If the DCS is not set to message class 2 then the message shall be handled in the normal way by the ME. However it has to be noted that MEs based on releases of this specification earlier than REL-5 may allow only 8 bit message class 2 with bit coding 11110110 or 00010110 for ANSI-136 R-DATA.

The TP-Data-Coding-Scheme is defined in TS 23.038.

The TP-Service-Centre-Time-Stamp field is given in semi-octet representation, and represents the local time in the following way:

The Time Zone indicates the difference, expressed in quarters of an hour, between the local time and GMT. In the first of the two semi-octets, the first bit (bit 3 of the seventh octet of the TP-Service-Centre-Time-Stamp field) represents the algebraic sign of this difference (0: positive, 1: negative). The Service-Centre-Time-Stamp, and any other times coded in this format that are defined in the present document, represent the time local to the sending entity. If the MS has knowledge of the local time zone, then any time received (e.g. Service-Centre-Time-Stamp) at the MS may be displayed in the local time rather than the time local to the sending entity. Messages shall be stored as received without change to any time contained therein. The Time Zone code enables the receiver to calculate the equivalent time in GMT from the other semi-octets in the Service-Centre-Time-Stamp, or indicate the time zone (GMT, GMT+1H etc.), or perform other similar calculations as required by the implementation. The value contained in the Time Zone field must take into account daylight saving time, such that when the sending entity changes from regular (winter) time to daylight saving (summer) time, there is a change to the value in the Time Zone field, for example in the UK the winter setting is 00000000 and the summer setting is 01000000. If the MS receives a non-integer value in the SCTS, it shall assume that the digit is set to 0 but shall store the entire field exactly as received.