The TP-Reject-Duplicates is a 1 bit field located within bit 2 of the first octet of SMS-SUBMIT and has the following values.
Bit no. 2:
0
Instruct the SC to 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.
1
Instruct the SC to reject an SMS-SUBMIT for an SM still held in the SC which has the same TP-MR and the same TP-DA as the previously submitted SM from the same OA. In this case the response returned by the SC is as specified in
clause 9.2.3.6.
The TP-Status-Report-Qualifier is a 1 bit field located within bit 5 of the first octet of SMS-STATUS-REPORT and has the following values
Bit no. 5:
0
The SMS-STATUS-REPORT is the result of a SMS-SUBMIT.
1
The SMS-STATUS-REPORT is the result of an SMS-COMMAND e.g. an Enquiry.
The TP-Parameter-Indicator comprises a number of octets between 1 and n where each bit when set to a 1 indicates that a particular optional parameter is present in the fields which follow. The TP-PI is present as part of the RP-User-Data in the RP-ACK or the RP-ERROR as indicated in
clauses 9.2.2.1a and
9.2.2.2a or the RP-DATA as indicated in
clause 9.2.2.3.
The structure of the TP-PI is as follows:
Octet 1:
The most significant bit in octet 1 and any other TP-PI octets which may be added later is reserved as an extension bit which when set to a 1 shall indicate that another TP-PI octet follows immediately afterwards.
If the TP-UDL bit is set to zero then by definition neither the TP-UDL field or the TP-UD field can be present. If the TP-UDL bit is set to
"1" but the TP-DCS bit is set to
"0" then the receiving entity shall for TP-DCS assume a value of 0x00, i.e. the 7bit default alphabet.
If a Reserved bit is set to
"1" then the receiving entity shall ignore the setting. The setting of this bit shall mean that additional information will follow the TP-User-Data, so a receiving entity shall discard any octets following the TP-User-Data.
The TP-Loop-Prevention is a 1-bit field, located within bit no 3 of the first octet of the SMS-Deliver and SMS-Status-Report, and to be given the values in the table below.
In the following description, a 'spawned' message refers to an application-generated message (e.g. an auto-reply or a copy to a second subscription) generated in response to a received SMS-Deliver or SMS-Status-Report. In order to prevent message loops, only a single off-net forwarding operation shall be permitted on any SMS-Deliver or SMS-Status-Report, and a spawned message shall not spawn a further message. To achieve this, spawned messages and forwarded messages (but not the original message) shall be marked using the TP-LP bit so that further spawning or further off-net forwarding of these messages is inhibited.
A network entity (e.g. an SC) that generates or transports SMS-Deliver or SMS-Status-Report shall set this bit in the forwarded message when forwarding to a destination other than that specified in the received SMS-Deliver or SMS-Status-Report.
A network entity (e.g. an SC) that implements SMS forwarding shall inhibit off-net forwarding of SMS-Deliver or SMS-Status-Report if this bit is already set in the SMS-Deliver or SMS-Status-Report received from another network.
If an implementation does not prevent on-net message looping by other means, a network entity (e.g. an SC) that implements SMS forwarding may inhibit on-net forwarding of SMS-Deliver or SMS-Status-Report if this bit is already set in the received SMS-Deliver or SMS-Status-Report.
A network entity (e.g. an SC) that spawns an additional message from a received SMS-Deliver or SMS-Status-Report shall set the TP-LP bit in the spawned message.
A network entity (e.g. an SC) shall inhibit generation of a spawned message if this bit is already set in the received SMS-Deliver or SMS-Status-Report from which the spawned message would otherwise be generated.