9.2.3 Definition of the TPDU parameters

23.0403GPPRelease 17Technical realization of the Short Message Service (SMS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

9.2.3.1 TP‑Message‑Type‑Indicator (TP‑MTI)

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.

9.2.3.2 TP‑More‑Messages‑to‑Send (TP‑MMS)

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:

Bit no 2: 0 More messages are waiting for the MS in this SC

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

Note: In the case of SMS‑STATUS‑REPORT this parameter refers to messages waiting for the mobile to which the status report is sent. The term message in this context refers to SMS‑messages or status reports.

9.2.3.3 TP‑Validity‑Period‑Format (TP‑VPF)

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.

9.2.3.4 TP‑Status‑Report‑Indication (TP‑SRI)

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:

Bit no. 5: 0 A status report shall not be returned to the SME
1 A status report shall be returned to the SME

9.2.3.5 TP‑Status‑Report‑Request (TP‑SRR)

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:

Bit no. 5: 0 A status report is not requested
1 A status report is requested

9.2.3.6 TP‑Message‑Reference (TP‑MR)

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 [16] and 3GPP TS 31.102 [30]) 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 3GPP TS 24.011 [13]) 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.

9.2.3.7 TP‑Originating‑Address (TP‑OA)

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.

9.2.3.8 TP‑Destination‑Address (TP‑DA)

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.

9.2.3.9 TP‑Protocol‑Identifier (TP‑PID)

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 : no interworking, but SME‑to‑SME protocol
value = 1 : telematic interworking

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 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)

00111 Videotex (T.100 [20] /T.101 [21])

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)

01110..01111 (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

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)

11111 A GSM/UMTS mobile station. The SC converts the SM from the received TP‑Data‑Coding‑Scheme 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 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 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

001000 Device Triggering Short Message

001001..011101 Reserved

011110 Enhanced Message Service (Obsolete)

011111 Return Call Message

100000..111011 Reserved

111100 ANSI-136 R-DATA

111101 ME Data download

111110 ME De‑personalization Short Message

111111 (U)SIM Data download

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 3GPP TS 22.022 [25]). 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 3GPP TS 22.022 [25]. 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 3GPP TS 22.022 [25].

(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 [16] and 3GPP TS 31.102 [30]. 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 3GPP TS 31.102 [30]. 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.

9.2.3.10 TP‑Data‑Coding‑Scheme (TP‑DCS)

The TP‑Data‑Coding‑Scheme is defined in 3GPP TS 23.038 [9].

9.2.3.11 TP‑Service‑Centre‑Time‑Stamp (TP‑SCTS)

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

	Year:	Month:	Day:	Hour:	Minute:	Second:	Time Zone
Digits: (Semi‑octets)	2	2	2	2	2	2	2

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.

9.2.3.12 TP‑Validity‑Period (TP-VP)

9.2.3.12.1 TP-VP (Relative format)

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 value	Validity period value
0 to 143	(TP‑VP + 1) x 5 minutes (i.e. 5 minutes intervals up to 12 hours)
144 to 167	12 hours + ((TP‑VP ‑143) x 30 minutes)
168 to 196	(TP‑VP ‑ 166) x 1 day
197 to 255	(TP‑VP ‑ 192) x 1 week

9.2.3.12.2 TP-VP (Absolute format)

The TP-Validity Period comprises 7 octets in semi octet representation giving the absolute time of the validity period termination.

The representation of time is identical to the representation of the TP‑Service‑Centre‑Time‑Stamp.

9.2.3.12.3 TP-VP (Enhanced format)

The TP-Validity Period comprises 7 octets. The presence of all octets is mandatory although they may not all be used. The first octet indicates the way in which the following 6 octets are used. Any reserved/unused bits or octets must be set to zero.

Octet 1 TP-VP functionality indicator

bit 7 Extension bit
Set to 1 if the TP-VP functionality indicator is to be extended to another octet. A setting of 0 indicates that there are no more TP-VP functionality indicator extension octets to follow.
Any such extension octet shall immediately follow the previous TP-VP functionality indicator.

bit 6 Single shot SM.
Set to 1 if the SC is required to make up to one delivery attempt. The TP-Validity Period, where present, shall be applicable to the Single shot SM.

bits 5, 4, 3 Reserved

bits 2, 1, 0 Validity Period Format.

Value bits	2 1 0
	0 0 0	No Validity Period specified
	0 0 1	Validity Period is as specified for the relative case. The following octet contains the TP-VP value as described in 9.2.3.12.1
	0 1 0	Validity period is relative in integer representation and the following octet contains the TP-VP value in the range 0 to 255 representing 0 to 255 seconds. A TP-VP value of zero is undefined and reserved for future use.
	0 1 1	Validity period is relative in semi-octet representation. The following 3 octets contain the relative time in Hours, Minutes and Seconds giving the length of the validity period counted from when the SMS-SUBMIT is received by the SC. The representation of time uses the same representation as the Hours, Minutes and Seconds in the TP‑Service‑Centre‑Time‑Stamp.
	1 0 0	Reserved
	1 0 1	Reserved
	1 1 0	Reserved
	1 1 1	Reserved

The SC shall reject any Unsupported/ Reserved values received by returning the ‘TP-VP not supported’ TP-FCS value in the Submit SM Report for RP-Error.

9.2.3.13 TP‑Discharge‑Time (TP‑DT)

The TP‑Discharge‑Time field indicates the time at which a previously submitted SMS‑SUBMIT was successfully delivered to or attempted to deliver to the recipient SME or disposed of by the SC.

In the case of "transaction completed" the time shall be the time of the completion of the transaction. In the case of "SC still trying to transfer SM" the time shall be the time of the last transfer attempt. In the case of "permanent or temporary error ‑ SC not making any more transfer attempts" the time shall be the time of either the last transfer attempt or the time at which the SC disposed of the SM according to the Status outcome in TP‑ST.

The TP‑Discharge‑Time is given in semi‑octet representation in a format identical to the TP‑SCTS.

9.2.3.14 TP‑Recipient‑Address (TP‑RA)

The TP‑Recipient‑Address field indicates the address of the SME that was the destination of the previously submitted mobile originated short message being subject to the status report. The field is formatted according to the formatting rules of address fields.

9.2.3.15 TP‑Status (TP‑ST)

The TP‑Status field indicates the status of a previously submitted SMS‑SUBMIT and certain SMS COMMANDS for which a Status ‑Report has been requested. It consists of one octet and the bits in the octet are used as follows.

The MS shall interpret any reserved values as "Service Rejected" (01100011) but shall store them exactly as received.

bits value/usage

7 0 Bits 0..6 as defined below:

6….0 Indicate whether the previously submitted short message was successfully forwarded to the SME, or whether an error condition has been encountered, as follows:

Short message transaction completed

0000000 Short message received by the SME
0000001 Short message forwarded by the SC to the SME but the SC is
unable to confirm delivery
0000010 Short message replaced by the SC

0000011..0001111 Reserved
0010000..0011111 Values specific to each SC

Temporary error, SC still trying to transfer SM

0100000 Congestion
0100001 SME busy
0100010 No response from SME
0100011 Service rejected
0100100 Quality of service not available
0100101 Error in SME

0100110..0101111 Reserved
0110000..0111111 Values specific to each SC

Permanent error, SC is not making any more transfer attempts

1000000 Remote procedure error
1000001 Incompatible destination
1000010 Connection rejected by SME
1000011 Not obtainable
1000100 Quality of service not available
1000101 No interworking available
1000110 SM Validity Period Expired
1000111 SM Deleted by originating SME
1001000 SM Deleted by SC Administration
1001001 SM does not exist (The SM may have previously existed in the SC but the SC no longer has knowledge of it or the SM
may never have previously existed in the SC)
1001010..1001111 Reserved
1010000..1011111 Values specific to each SC

Temporary error, SC is not making any more transfer attempts

1100000 Congestion
1100001 SME busy
1100010 No response from SME
1100011 Service rejected
1100100 Quality of service not available
1100101 Error in SME
1100110..1101001 Reserved
1101010..1101111 Reserved
1110000..1111111 Values specific to each SC

bits value/usage

7 1 Bits 0..6 reserved

9.2.3.16 TP‑User‑Data‑Length (TP‑UDL)

If the TP‑User‑Data is coded using the GSM 7 bit default alphabet, the TP‑User‑Data‑Length field gives an integer representation of the number of septets within the TP‑User‑Data field to follow. If the 7bit default-alphabet extension mechanism is used within the TP‑User‑Data (see 3GPP TS 23.038 [9]), the actual number of characters in the message shall be less than the number of septets. If a TP‑User‑Data‑Header field is present, then the TP‑User‑Data‑Length value is the sum of the number of septets in the TP‑User‑Data‑Header field (including any padding) and the number of septets in the TP‑User‑Data field which follows. See figure 9.2.3.24 (a). If the TP‑User‑Data is coded using 8‑bit data, the TP‑User‑Data‑Length field gives an integer representation of the number of octets within the TP‑User‑Data field to follow. If a TP‑User‑Data‑Header field is present, then the TP‑User‑Data‑Length value is the sum of the number of octets in the TP‑User‑Data‑Header field and the number of octets in the TP‑User‑Data field which follows. See figure 9.2.3.24 (b).

If the TP‑User‑Data is coded using UCS2 [24] data, the TP‑User‑Data‑Length field gives an integer representation of the number of octets within the TP‑User‑Data field to follow. If a TP‑User‑Data‑Header field is present, then the TP‑User‑Data‑Length value is the sum of the number of octets in the TP‑User‑Data‑Header field and the number of octets in the TP‑User‑Data field which follows. See figure 9.2.3.24 (b).

If the TP‑User‑Data is coded using compressed GSM 7 bit default alphabet or compressed 8 bit data or compressed UCS2 [24] data, the TP‑User‑Data‑Length field gives an integer representation of the number of octets after compression within the TP‑User‑Data field to follow. If a TP‑User‑Data‑Header field is present, then the TP‑User‑Data‑Length value is the sum of the number of uncompressed octets in the TP‑User‑Data‑Header field and the number of octets in the compressed TP‑User‑Data field which follows. See figure 9.2.3.24 (c).

For other Data Coding Schemes, see 3GPP TS 23.038 [9]. If this field is zero, the TP‑User‑Data field shall not be present.

9.2.3.17 TP‑Reply‑Path (TP‑RP)

The TP‑Reply‑Path is a 1‑bit field, located within bit no 7 of the first octet of both SMS‑DELIVER and SMS‑SUBMIT, and to be given the following values:

Bit no 7: 0 TP‑Reply‑Path parameter is not set in this SMS‑SUBMIT/DELIVER

1 TP‑Reply‑Path parameter is set in this SMS‑SUBMIT/DELIVER

Please refer to annex D for details about the Reply procedures.

9.2.3.18 TP‑Message‑Number (TP‑MN)

The TP‑Message‑Number is an 8‑bit field allowing an MS to refer uniquely to an SM in the SC which that MS has previously submitted. The TP‑MN value is the TP‑MR value of a previously submitted SM.

9.2.3.19 TP‑Command‑Type (TP‑CT)

The TP‑Command‑Type is an 8‑bit field specifying the type of operation that the SC is to perform. It has the following values:

Value (bit 7 .. 0)	Command Description	Status Report Request Value
00000000	Enquiry relating to previously submitted short message	1
00000001	Cancel Status Report Request relating to previously submitted short message	0
00000010	Delete previously submitted Short Message	0
00000011	Enable Status Report Request relating to previously submitted short message	0
00000100..00011111	Reserved	unspecified
11100000..11111111	Values specific for each SC	1 or 0

The SC shall return an RP‑Error with an appropriate TP‑Failure‑Cause for any TP‑Command value which is reserved, unsupported or invalid or the actioning of the command has failed.

The SC shall return an RP‑ACK if the actioning of the Command has succeeded.

A successful Enquiry shall result in the SC sending a SMS‑STATUS‑REPORT for the SM to which the Enquiry refers. In the case where the SC has a number of SMs which have the same TP‑MR, the same TP‑DA and have come from the same originating address the SC shall send a SMS‑STATUS‑REPORT for each SM.

In the case where a TP‑Command is to Delete a previously submitted short message, the SC shall send a Status Report indicating that the SM has been deleted if the original Submit SM request requested a status Report.

9.2.3.20 TP‑Command‑Data‑Length (TP‑CDL)

The TP‑Command‑Data‑Length field is used to indicate the number of octets contained within the TP‑Command‑Data‑field. If this field is set to zero, the TP‑Command‑Data field shall not be present.

9.2.3.21 TP‑Command‑Data (TP‑CD)

The TP‑Command‑Data field contains data relating to the operation requested by the MS which is to be performed at the SC. The maximum length of this field is 157 octets. The usage and provision of the optional TP‑Command‑Data field shall be determined by the function selected by the TP‑Command‑Type field.

9.2.3.22 TP‑Failure‑Cause (TP‑FCS)

The TP‑Failure‑Cause field is used to report the reason for failure to transfer or process a short message. It consists of a single octet used as follows:

TP-FCS Value (Hex)	Meaning	When used
		MO	MT
00 – 7F	Reserved

80 – 8F	TP-PID errors
80	Telematic interworking not supported	x
81	Short message Type 0 not supported	x	x
82	Cannot replace short message	x	x
83 – 8E	Reserved
8F	Unspecified TP-PID error	x	x

90 – 9F	TP-DCS errors
90	Data coding scheme (alphabet) not supported	x
91	Message class not supported		x
92 – 9E	Reserved
9F	Unspecified TP-DCS error	x	x

A0 – AF	TP-Command Errors
A0	Command cannot be actioned	x
A1	Command unsupported	x
A2 – AE	Reserved
AF	Unspecified TP-Command error	x

B0	TPDU not supported	x	x
B1 – BF	Reserved

C0	SC busy	x
C1	No SC subscription	x
C2	SC system failure	x
C3	Invalid SME address	x
C4	Destination SME barred	x
C5	SM Rejected-Duplicate SM	x
C6	TP-VPF not supported	X
C7	TP-VP not supported	X
C8 – CF	Reserved

D0	(U)SIM SMS storage full		x
D1	No SMS storage capability in (U)SIM		x
D2	Error in MS		x
D3	Memory Capacity Exceeded		X
D4	(U)SIM Application Toolkit Busy		x
D5	(U)SIM data download error		x
D6 – DF	Reserved

E0 – FE	Values specific to an application	x	x

FF	Unspecified error cause	x	x

NOTE: Any reserved codes which are received should be treated as an unspecified error cause.
MT and MO refer to the overall mobile terminated and mobile originated services; not the direction of transmission of TP‑FCS.

9.2.3.23 TP‑User‑Data‑Header‑Indicator (TP‑UDHI)

The TP‑User‑Data‑Header‑Indicator is a 1 bit field within bit 6 of the first octet of the following six PDUs:

– SMS‑SUBMIT,

– SMS-SUBMIT-REPORT,

– SMS‑DELIVER,

– SMS-DELIVER-REPORT,

– SMS-STATUS-REPORT,

– SMS-COMMAND.

TP-UDHI has the following values.

Bit no. 6 0 The TP‑UD field contains only the short message

1 The beginning of the TP‑UD field contains a Header in addition to the short message.

9.2.3.24 TP‑User Data (TP‑UD)

The length of the TP-User-Data field is defined in the PDU’s of the SM-TL (see clause 9.2.2).

The TP‑User‑Data field may comprise just the short message itself or a Header in addition to the short message depending upon the setting of TP‑UDHI.

Where the TP‑UDHI value is set to 0 the TP‑User‑Data field comprises the short message only, where the user data can be 7 bit (default alphabet) data, 8 bit data, or 16 bit (UCS2 [24]) data.

Where the TP‑UDHI value is set to 1 the first octets of the TP‑User‑Data field contains a Header in the following order starting at the first octet of the TP‑User‑Data field.

Irrespective of whether any part of the User Data Header is ignored or discarded, the MS shall always store the entire TPDU exactly as received.

FIELD LENGTH

Length of User Data Header 1 octet

Information‑Element‑Identifier "A" 1 octet

Length of Information‑Element "A" 1 octet

Information‑Element "A" Data 0 to "n" octets

Information‑Element‑Identifier "B" 1 octet

Length of Information‑Element "B" 1 octet

Information‑Element "B" Data 0 to "n" octets

Information‑Element‑Identifier "X" 1 octet

Length of Information‑Element "X" 1 octet

Information‑Element "X" Data 0 to "n" octets

The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed GSM 7 bit default alphabet data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.

Figure 9.2.3.24 (a)

The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for uncompressed 8 bit data or uncompressed UCS2 data. The UDHL field is the first octet of the TP-User-Data content of the Short Message.

Figure 9.2.3.24 (b)

The diagram below shows the layout of the TP-User-Data-Length and the TP-User-Data for compressed GSM 7 bit default alphabet data, compressed 8 bit data or compressed UCS2 data. The UDHL field is the first octet of the TP‑User-Data content of the Short Message.

Figure 9.2.3.24 (c)

The definition of the TP‑User‑Data‑Length field which immediately precedes the "Length of User Data Header" is unchanged and shall therefore be the total length of the TP‑User‑Data field including the Header, if present. (see 9.2.3.16).

The "Length‑of‑Information‑Element" fields shall be the integer representation of the number of octets within its associated "Information‑Element‑Data" field which follows and shall not include itself in its count value.

The "Length‑of‑User‑Data‑Header" field shall be the integer representation of the number of octets within the "User‑Data‑Header" information fields which follow and shall not include itself in its count or any fill bits which may be present (see text below).

Information Elements may appear in any order and need not follow the order used in the present document. Information Elements are classified into 3 categories as described below.

– SMS Control – identifies those IEIs which have the capability of dictating SMS functionality.

– EMS Control – identifies those IEIs which manage EMS Content IEIs.

– EMS Content – identifies those IEIs containing data of a unique media format.

It is permissible for certain IEs to be repeated within a short message, or within a concatenated message. There is no restriction on the repeatability of IEs in the EMS Content classification. The repeatability of SMS Control and EMS Control IEs is determined on an individual basis. See the IE table below for the repeatability of each IE.

In the event that IEs determined as not repeatable are duplicated, the last occurrence of the IE shall be used. In the event that two or more IEs occur which have mutually exclusive meanings (e.g. an 8bit port address and a 16bit port address), then the last occurring IE shall be used.

If the length of the User Data Header is such that there are too few or too many octets in the final Information Element then the whole User Data Header shall be ignored.

If any reserved values are received within the content of any Information Element then that part of the Information Element shall be ignored.

The support of any Information Element Identifier is optional unless otherwise stated.

The Information Element Identifier octet shall be coded as follows:

VALUE (hex)	MEANING	Classification	Repeatability
00	Concatenated short messages, 8-bit reference number	SMS Control	No
01	Special SMS Message Indication	SMS Control	Yes
02	Reserved	N/A	N/A
03	Value not used to avoid misinterpretation as <LF> character	N/A	N/A
04	Application port addressing scheme, 8 bit address	SMS Control	No
05	Application port addressing scheme, 16 bit address	SMS Control	No
06	SMSC Control Parameters	SMS Control	No
07	UDH Source Indicator	SMS Control	Yes
08	Concatenated short message, 16-bit reference number	SMS Control	No
09	Wireless Control Message Protocol	SMS Control	Note 3
0A	Text Formatting	EMS Control	Yes
0B	Predefined Sound	EMS Content	Yes
0C	User Defined Sound (iMelody max 128 bytes)	EMS Content	Yes
0D	Predefined Animation	EMS Content	Yes
0E	Large Animation (1616 times 4 = 324 =128 bytes)	EMS Content	Yes
0F	Small Animation (88 times 4 = 84 =32 bytes)	EMS Content	Yes
10	Large Picture (32*32 = 128 bytes)	EMS Content	Yes
11	Small Picture (16*16 = 32 bytes)	EMS Content	Yes
12	Variable Picture	EMS Content	Yes
13	User prompt indicator	EMS Control	Yes
14	Extended Object	EMS Content	Yes
15	Reused Extended Object	EMS Control	Yes
16	Compression Control	EMS Control	No
17	Object Distribution Indicator	EMS Control	Yes
18	Standard WVG object	EMS Content	Yes
19	Character Size WVG object	EMS Content	Yes
1A	Extended Object Data Request Command	EMS Control	No
1B-1F	Reserved for future EMS features (see clause 3.10)	N/A	N/A
20	RFC 5322 E-Mail Header	SMS Control	No
21	Hyperlink format element	SMS Control	Yes
22	Reply Address Element	SMS Control	No
23	Enhanced Voice Mail Information	SMS Control	No
24	National Language Single Shift	SMS Control	No
25	National Language Locking Shift	SMS Control	No
26 – 6F	Reserved for future use	N/A	N/A
70 – 7F	(U)SIM Toolkit Security Headers	SMS Control	Note 1
80 – 9F	SME to SME specific use	SMS Control	Note 2
A0 – BF	Reserved for future use	N/A	N/A
C0 – DF	SC specific use	SMS Control	Note 2
E0 – FF	Reserved for future use	N/A	N/A
Note 1: The functionality of these IEIs is defined in 3GPP TSG 31.115 [28], and therefore, the repeatability is not within the scope of this document and will not be determined here. Note 2: The functionality of these IEIs is used in a proprietary fashion by different SMSC vendors, and therefore, are not within the scope of this technical specification. Note 3: The functionality of these IEIs is defined by the WAP Forum and therefore the repeatability is not within the scope of this document and will not be determined here.

A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) any information element where the IEI is Reserved or not supported. The receiving entity calculates the start of the next information element by looking at the length of the current information element and skipping that number of octets.

The SM itself may be coded as 7, 8 or 16 bit data.

If 7 bit data is used and the TP‑UD‑Header does not finish on a septet boundary then fill bits are inserted after the last Information Element Data octet up to the next septet boundary so that there is an integral number of septets for the entire TP‑UD header. This is to ensure that the SM itself starts on an septet boundary so that an earlier Phase mobile shall be capable of displaying the SM itself although the TP‑UD Header in the TP‑UD field may not be understood.

It is optional to make the first character of the SM itself a Carriage Return character encoded according to the default 7 bit alphabet so that earlier Phase mobiles, which do not understand the TP‑UD‑Header, shall over‑write the displayed TP‑UD‑Header with the SM itself.

If 16 bit (USC2) data is used then padding octets are not necessary. The SM itself shall start on an octet boundary.

If 8 bit data is used then padding is not necessary. An earlier Phase mobile shall be able to display the SM itself although the TP‑UD header may not be understood.

It is also possible for mobiles not wishing to support the TP‑UD header to check the value of the TP‑UDHI bit in the SMS‑Deliver PDU and the first octet of the TP‑UD field and skip to the start of the SM and ignore the TP‑UD header.

9.2.3.24.1 Concatenated Short Messages

This facility allows short messages to be concatenated to form a longer message.

In the case of uncompressed 8‑bit data, the maximum length of the short message within the TP‑UD field is 134 (140‑6) octets.

In the case of uncompressed GSM 7 bit default alphabet data, the maximum length of the short message within the TP‑UD field is 153 (160‑7) characters. A character represented by an escape-sequence shall not be split in the middle.

In the case of 16 bit uncompressed USC2 data, the maximum length of the short message within the TP‑UD field is 67 ((140‑6)/2) characters. A UCS2 character shall not be split in the middle; if the length of the User Data Header is odd, the maximum length of the whole TP-UD field is 139 octets.

In the case of compressed GSM 7 bit default alphabet data, 8 bit data or UCS2 the maximum length of the compressed short message within the TP-UD field is 134 (140-6) octets including the Compression Header and Compression Footer, both or either of which may be present (see clause 3.9).

The maximum length of an uncompressed concatenated short message is 39015 (255*153) default alphabet characters, 34170 (255*134) octets or 17085 (255*67) UCS2 characters.

The maximum length of a compressed concatenated message is 34170 (255*134) octets including the Compression Header and Compression Footer (see clause 3.9 and figure 9.2.3.24.1(a) below).

Figure 9.2.3.24.1 (a): Concatenation of a Compressed short message

The Information‑Element‑Data field contains information set by the application in the SMS‑SUBMIT so that the receiving entity is able to re‑assemble the short messages in the correct order. Each concatenated short message contains a reference number which together with the originating address and Service Centre address allows the receiving entity to discriminate between concatenated short messages sent from different originating SMEs and/or SCs. In a network which has multiple SCs, it is possible for different segments of a concatenated 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.

The TP elements in the SMS‑SUBMIT PDU, apart from TP‑MR, TP-SRR, TP‑UDL and TP‑UD, should remain unchanged for each SM which forms part of a concatenated SM, otherwise this may lead to irrational behaviour. TP-MR must be incremented for every segment of a concatenated message as defined in clause 9.2.3.6. A SC shall handle segments of a concatenated message like any other short message. The relation between segments of a concatenated message is made only at the originator, where the message is segmented, and at the recipient, where the message is reassembled. SMS‑COMMANDs identify messages by TP-MR and therefore apply to only one segment of a concatenated message. It is up to the originating SME to issue SMS-COMMANDs for all the required segments of a concatenated message.

The Information‑Element‑Data octets shall be coded as follows.

Octet 1 Concatenated short message reference number.

This octet shall contain a modulo 256 counter indicating the reference number for a particular concatenated short message. This reference number shall remain constant for every short message which makes up a particular concatenated short message.

Octet 2 Maximum number of short messages in the concatenated short message.

This octet shall contain a value in the range 0 to 255 indicating the total number of short messages within the concatenated short message. The value shall start at 1 and remain constant for every short message which makes up the concatenated short message. If the value is zero then the receiving entity shall ignore the whole Information Element.

Octet 3 Sequence number of the current short message.

This octet shall contain a value in the range 0 to 255 indicating the sequence number of a particular short message within the concatenated short message. The value shall start at 1 and increment by one for every short message sent within the concatenated short message. If the value is zero or the value is greater than the value in octet 2 then the receiving entity shall ignore the whole Information Element.

The IEI and associated IEI length and IEI data shall be present in every segment of the concatenated SM.

9.2.3.24.2 Special SMS Message Indication

There are three levels of "Message Waiting" indication provided within the present document. The first level is to set the Protocol Identifier to "Return Call message", which indicates that a message is waiting and relies on the text of the message to supply the detail. The second level uses the Data Coding Scheme with or without Return Call Message (see 3GPP TS 23.038 [9]) to indicate the type of message waiting and whether there are some messages or no messages. The third level is described here, and provides the maximum detail level for analysis by the mobile, i.e. an indication of the number and type of messages waiting in systems connected to the PLMN.

This information shall be stored by the ME in the Message Waiting Indication Status on the SIM (see 3GPP TS 51.011 [16]) or USIM (see 3GPP TS 31.102 [30]) when present or otherwise should be stored in the ME. In case there are multiple records of EF_MWIS this information shall be stored within the record according to the profile if available – or otherwise within the first record.

The number of messages shall be stored in Message Waiting Indication Status and an indicator should be shown if the number of messages is non‑zero or removed if the number of messages is zero. The ME may also provide some MMI to indicate and access the actual number of messages waiting. Text may be included by the SMS Service Centre for backward compatibility with the earliest Phase mobiles and the Data Coding Scheme may also be used to convey this information in parallel for backward compatibility with "middle" Phase mobiles (which support the use of Data Coding Scheme for Message Waiting Indication but not the use of TP‑UDH for Message Waiting Indication).

The information‑Element octets shall be coded as follows:

Octet 1 Message Indication type and Storage.

Bit 7 Indicates whether or not the message shall be stored.

Bit 7

0 Discard message after updating indication

1 Store message after updating indication

In the event of a conflict between this setting and the setting of the Data Coding Scheme (see 3GPP TS 23.038 [9]) then the message shall be stored if either the DCS indicates this, or Octet 1 above indicates this.

Bits 0 and 1 indicate the basic message indication type.

00 Voice Message Waiting
01 Fax Message Waiting
10 Electronic Mail Message Waiting
11 Extended Message Type Waiting (equivalent to "other" in 3GPP TS 23.038 [9])

Bits 432 indicate the extended message indication type.

000 No extended message indication type.
001 Video Message Waiting

Other values of bits 432 where bits 0 and 1 are ’11’ are Reserved for future use in the present document.

Values of bits 432 where bits 0 and 1 are ’00’, ’01’ or ’10’ are Reserved for future use in the present document.

NOTE: Values using bits 432 where bits 0 and 1 are ’11’ should be exhausted before using the remaining codespace due to existing early implementations erroneously using parts of this codespace.

Bits 6 and 5 indicate the profile ID of the Multiple Subscriber Profile (see 3GPP TS 23.097 [41]).

00 profile ID 1
01 profile ID 2
10 profile ID 3
11 profile ID 4

Terminals should be capable of receiving any values in octet 1, including those marked as Reserved. Terminals may add the Message Count of all unknown Message Waiting Indication types received within the same TP-UDH and indicate this result to the user.

Octet 2 Message Count.

This octet shall contain a value in the range 0 to 255 indicating the number of messages of the type specified in Octet 1 waiting. The value 255 shall be taken to mean 255 or greater. In the event of a conflict between this setting and the setting of the Data Coding Scheme (see 3GPP TS 23.038 [9]) then the Message Count in the TP‑UDH shall override the indication in the TP‑DCS.

If more than one type of message is required to be indicated within one SMS message, then further octets must be used, as in the following example:

[00] TP‑UDL [1E] (30 decimal septets)

[01] Length of TP‑UDH [08]

[02] IEI = Special SMS Message Indication [01]

[03] Length = 02

[04] Octet 1 = Voice Mail, do not store [00]

[05] Octet 2 = 04 Messages

[06] IEI = Special SMS Message Indication [01]

[07] Length = 02

[08] Octet 1 = Fax Mail, Store [81]

[09] Octet 2 = 02 Messages

+ 5 Fill bits

+ 19 seven‑bit character message text

The Total number of bits is 210.

In the case where this IEI is to be used in a concatenated SM then the IEI, its associated IEI length and IEI data shall be contained in the first segment of the concatenated SM. The IEI, its associated IEI length and IEI data should also be contained in every subsequent segment of the concatenated SM although this is not mandatory. However, in the case where these elements are not contained in every subsequent segment of the concatenated SM and where an out of sequence segment delivery occurs or where the first segment is not delivered then processing difficulties may arise at the receiving entity which may result in the concatenated SM being totally or partially discarded.

9.2.3.24.3 Application Port Addressing 8 bit address

This facility allows short messages to be routed to one of multiple applications, using a method similar to TCP/UDP ports in a TCP/IP network. An application entity is uniquely identified by the pair of TP-DA/TP-OA and the port address. The port addressing is transparent to the transport, and also useful in Status Reports.

The total length of the IE is 2 octets:

octet 1 Destination port.

This octet contains a number indicating the receiving port, i.e. application, in the receiving device.

octet 2 Originator port.

This octet contains a number indicating the sending port, i.e. application, in the sending device.

The port range is up to 255 using 8 bit addressing space. The Integer value of the port number is presented as in 3GPP TS 23.040 clause 9.1.2.1.

VALUE (port number) MEANING

0 ‑ 239 Reserved
240 ‑ 255 Available for allocation by applications

A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) any information element where the value of the Information-Element-Data is Reserved or not supported.

In the case where this IE is to be used in a concatenated SM then the IEI, its associated IEI length and IEI data shall be contained in the first segment of the concatenated SM. The IEI, its associated IEI length and IEI data shall also be contained in every subsequent segment of the concatenated SM.

9.2.3.24.4 Application Port Addressing 16 bit address

The total length of the IE is 4 octets:

octet 1,2 Destination port.

These octets contain a number indicating the receiving port, i.e. application, in the receiving device.

octet 3,4 Originator port.

These octets contain a number indicating the sending port, i.e. application, in the sending device.

The port range is up to 65535 using 16 bit addressing space. The Integer value of the port number is presented as in 3GPP TS 23.040 clause 9.1.2.1.

VALUE (port number) MEANING

0 ‑ 15999 UDP/TCP port numbers assigned by IANA without the need to refer to 3GPP. For the procedure, use and assignment of port numbers in this range – refer to the IANA database. (http://www.IANA.com/). See Note 1.

16000 ‑ 16999 Available for allocation by SMS applications without the need to refer to 3GPP or IANA. See Note 2.

17000 ‑ 49151 UDP/TCP port numbers assigned by IANA. For the procedure, use and assignment of port numbers in this range – refer to the IANA database. (http://www.IANA.com/). See Note 1.

49152 Trigger to establish a PDN connection of non-IP PDN type using the default APN.

49153 – 65535 Reserved for future allocation by 3GPP. For a port number in this range an application must be made to 3GPP.

NOTE 1: The value used for this field by a particular application is the same value that the application would use when using a UDP or a TCP transport. Therefore, applications that register a UDP or TCP port with the IANA need to use the same registered value for this field. UDP and TCP ports are registered separately. Therefore, it is necessary to check the application since the fact that a particular TCP port is registered (e.g., for HTTP) does not mean that its corresponding UDP port will be also registered for the same application.

NOTE 2: Port numbers in the range 16000 – 16999 are assigned by IANA for UDP and TCP transport. The range is not allocated by 3GPP and is available for any SMS application. There is a risk of port numbers in this range having conflicting applications. If it is desirable to avoid such a conflict then an application for a port number in the range 49152 – 65535 is to be made to 3GPP.

9.2.3.24.5 SMSC Control Parameters

The facility enables the SMS protocol headers to be expanded using a flexible method. It may be used to control the SMSC, but is also passed transparently to the receiving mobile. The Information Element must be present in every short message affected by it, i.e. in every short message in a concatenated message.

The Information Element data octets shall be coded as follows:

octet 1 Selective Status Report.

This facility is used to control the creation of Status Reports, depending on the error code of the particular message. It is also used by the sending entity to request inclusion of the original UDH into the Status Report. In this case the original UDH must be separated from the rest of the UDH using the Source Indicator. The TP-SRR must be set in order for the Selective Status Report to be enabled. The bits are defined as follows:

bit 0

0 No Status Report for short message transaction completed

1 Status Report for short message transaction completed

bit 1

0 No Status Report for permanent error when SC is not making any more transfer attempts

1 Status Report for permanent error when SC is not making any more transfer attempts

bit 2

0 No Status Report for temporary error when SC is not making any more transfer attempts

1 Status Report for temporary error when SC is not making any more transfer attempts

bit 3

0 No Status Report for temporary error when SC is still trying to transfer SM

1 Status Report for temporary error when SC is still trying to transfer SM

bits 4 and 5

reserved for future use.

bit 6

0 No activation

1 A Status Report generated by this Short Message, due to a permanent error or last temporary error, cancels the SRR of the rest of the Short Messages in a concatenated message. This feature can only be used where a SC is aware of the segmentation of a concatenated SM and is therefore an implementation matter.

bit 7

0 Do not include original UDH into the Status Report

1 Include original UDH into the Status Report

9.2.3.24.6 UDH Source Indicator

The facility is used to separate the UDH of the original message, a UDH created by the SMSC, and a UDH provided by the original receiving entity. The Source Indicator is placed in front of the content inserted by the source. The indicated content (one or more Information-Elements) ends at the next UDH-Source-Indicator, or at the end of the UDH. The Separator is intended to be used especially in Status Reports, but can also be used by the SMSC to add information into Short Message (for example Message waiting). The default content for a UDH in a SMS-DELIVERY is the headers inserted by the sending device, and the default content for a UDH in a SMS-STATUS-REPORT is the headers copied from the SMS-DELIVERY-REPORT.

Values of octet:

01 The following part of the UDH is created by the original sender (valid in case of Status Report)

02 The following part of the UDH is created by the original receiver (valid in case of Status Report)

03 The following part of the UDH is created by the SMSC (can occur in any message or report)

9.2.3.24.7 (U)SIM Toolkit Security Headers

There are no IEI data values associated with these IEI values and so the associated Length of Information element field is present but set to zero.

These IEI values implicitly define that a Security Header is always present at the start of the TP-User-Data field which immediately follows the TP-User-Data-Header. Details of the Security Header will be found in TS 31.115 [28].

In the case where a concatenated message contains a Security Header then the Security Header will only be present in the first segment of a concatenated message.

In the case where SMS compression is applied to a TP-User-Data field which contains a Security Header then the SMS compression header (3GPP TS 23.042 [26]) shall immediately precede the Security Header.

9.2.3.24.8 Concatenated short messages, 16-bit reference number

This facility is an enhanced variant of the Concatenated Short Message facility (see clause 9.2.3.24.1). The enhancement is a 16-bit reference number, instead of the short 8-bit reference number. The larger reference number reduces the probability that two different concatenated messages are mistakenly sent with identical reference numbers to a receiver. Except for the size of the reference number this facility is identical to the Concatenated Short Message facility (see clause 9.2.3.24.1).

In the case of uncompressed 8‑bit data, the maximum length of the short message within the TP‑UD field is 133 (140‑7) octets.

In the case of uncompressed GSM 7 bit default alphabet data, the maximum length of the short message within the TP‑UD field is 152 (160‑8) characters. A character represented by an escape-sequence shall not be split in the middle.

In the case of 16 bit uncompressed USC2 data, the maximum length of the short message within the TP‑UD field is 66 ((140‑7)/2) characters. A UCS2 character shall not be split in the middle; if the length of the User Data Header is odd, the maximum length of the whole TP-UD field is 139 octets.

In the case of compressed GSM 7 bit default alphabet data, 8 bit data or UCS2 the maximum length of the compressed short message within the TP-UD field is 133 (140‑7) octets including the Compression Header and Compression Footer, both or either of which may be present (see clause 3.9).

The relation between compression and concatenation is the same as for Concatenated Short Messages (see clause 9.2.3.24.1).

The TP elements in the SMS‑SUBMIT PDU, apart from TP‑MR, TP‑UDL and TP‑UD, should remain unchanged for each SM which forms part of a concatenated SM, otherwise this may lead to irrational behaviour. TP-MR must be incremented for every segment of a concatenated message as defined in clause 9.2.3.6. A SC shall handle segments of concatenated message like any other short message. The relation between segments of a concatenated message is made at the originator, where the message is segmented, and at the recipient, where the message is reassembled. SMS-COMMANDs identify messages by TP-MR and therefore apply to only one segment of a concatenated message. It is up to the originating SME to issue SMS-COMMANDs for all the required segments of a concatenated message.

The Information‑Element‑Data octets shall be coded as follows:

Octet 1-2 Concatenated short messages, 16-bit reference number.

This octet shall contain a modulo 65536 counter indicating the reference number for a particular enhanced concatenated short message. This reference number shall remain constant for every short message which makes up a particular enhanced concatenated short message.

Octet 3 Maximum number of short messages in the enhanced concatenated short message.

This octet shall contain a value in the range 0 to 255 indicating the total number of short messages within the concatenated short message. The value shall start at 1 and remain constant for every short message which makes up the enhanced concatenated short message. If the value is zero then the receiving entity shall ignore the whole Information Element.

Octet 4 Sequence number of the current short message.

This octet shall contain a value in the range 0 to 255 indicating the sequence number of a particular short message within the concatenated short message. The value shall start at 1 and increment by one for every short message sent within the concatenated short message. If the value is zero or the value is greater than the value in octet 3 then the receiving entity shall ignore the whole Information Element.

The IEI and associated IEI length and IEI data shall be present in every segment of the concatenated SM.

9.2.3.24.9 Wireless Control Message Protocol

The Wireless Control Message Protocol (WCMP) is part of the WAP suite of protocols; an open standard specified by the WAP Forum Ltd.

The protocol specifies a set of messages that can be used by the receiver to notify the sender if an error occurs. This can be due to routing problems, no application listening at the destination port number, or due to insufficient buffer capacity. The error messages can be used by the sender to avoid retransmitting packets, that can not be properly handled at the receiver. WCMP can also be used for diagnostics and informational purposes. WCMP messages are usually generated by a datagram transport layer or a management entity.

The Information‑Element‑Data octet(s) shall be coded as follows:

Octet 1-n Protocol Data Unit of WCMP.

This octet(s) shall contain a WCMP protocol data unit.

9.2.3.24.10 Enhanced Messaging Service

9.2.3.24.10.1 EMS Coding

Enhanced Messaging is based on standard mechanism in GSM SMS messaging. The first mechanism is called user data header (TP-UDH), which makes it possible to include binary data in a normal SM prior the text message itself (clause 9.2.3.24). The binary data is in the TP-UD field (message), which means that it steels a part of the 140 bytes.
Each object within the SM shall be identified by a IE in the TP-UD Header. The IE will contain a octet (refer to
clause 9.2.3.24.10.1) that identifies the absolute position of the object within and from the beginning of the SM data. In case of formatting text, an additional octet will give the number of characters for which the formatting applies. Next mechanism that is used is concatenation, see clause 9.2.3.24.1. This mechanism permits longer messages than 140 bytes, in fact 255 messages a 140 bytes each can be concatenated to one message up to about 38k bytes.

EMS IEs of the same type may occur more than once in a single message or one segment of a concatenated SM.

9.2.3.24.10.1.1 Text Formatting

The Information‑Element‑Data octet(s) shall be coded as follows:

Octet 1 Start position of the text formatting. Set to the number of characters after the formatting shall be applied from the beginning of the SM data.

This octet shall be coded as an integer value in the range 0 (beginning of the SM data) to the maximum number of characters included in the SM data of one single SM or one segment of a concatenated SM.

Octet 2 Text formatting length. Gives the number of formatted characters or sets a default text formatting.

This octet shall be coded as an integer value in the range 1 to the maximum number of characters for which the formatting applies in one single SM or one segment of a concatenated SM.

A text formatting length value of 0 indicates that the text format shall be used as a default text format for the current SM. The default text format shall be used for all text in a concatenated SM unless temporarily overridden by a text formatting IE with a non-zero text format length field.

It shall be possible to re-define the default text formatting to be applied to all subsequent text in the current SM by sending a new Text Format IE with text format length zero.

Conflicting overlapping text formatting instructions shall be resolved by applying the formatting instructions in their sequential order.

Octet 3 formatting mode value coded as following:

Octet 3: Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Bit 1 Bit 0 *Alignment
0 0 Left
0 1 Center
1 0 Right
1 1 Language dependent (default)

*in case formatting text is inserted on the same line as previous non formatting text or with a different mode value, the alignment value shall be set to the same value as the previous formatted predefined object.

Alignment may affect object placement.

Bit 3 Bit 2 Font Size
0 0 Normal (default)
0 1 Large
1 0 Small
1 1 reserved

Bit 4 Style bold
1 Bold on
0 Bold off

Bit 5 Style Italic
1 Italic on
0 Italic off

Bit 6 Style Underlined
1 Underlined on
0 Underlined off

Bit 7 Style ~~Strikethrough~~
1 Strikethrough on
0 Strikethrough off

If bit 4,5,6 and 7 are set to 0, it will mean normal style (default).

Octet 4 Text Colour.

This Octet may be omitted by setting the IED length accordingly.

Bits 0..3 define the Text Foreground Colour

Bits 4..7 define the Text Background Colour

Each colour is defined in a semi octet according to the table below. The actual colours displayed may vary between ME’s depending on the display device used.

The colour values defined are simple primary and secondary colours plus four levels of grey. Bright colours have a higher intensity than dark colours.

Nibble Value Colour

(msb…lsb)

0000 Black

0001 Dark Grey

0010 Dark Red

0011 Dark Yellow

0100 Dark Green

0101 Dark Cyan

0110 Dark Blue

0111 Dark Magenta

1000 Grey

1001 White

1010 Bright Red

1011 Bright Yellow

1100 Bright Green

1101 Bright Cyan

1110 Bright Blue

1111 Bright Magenta

9.2.3.24.10.1.2 Predefined Sound

The Information‑Element‑Data octet(s) shall be coded as follows.

Octet 1 position indicating in the SM data the instant after which the sound shall be played. It will be set to the number of characters from the beginning of the SM data after which the sound shall be played.

Octet 2 sound number. Shall be encoded as a integer value.

9.2.3.24.10.1.3 User Defined Sound

The Information‑Element‑Data octet(s) shall be coded as follows.

Octet 1 position indicating in the SM data the instant the after which the sound shall be played (refer to clause
9.2.3.24.10.1.2).

Octet 2-n Protocol Data Unit as described in clause 9.2.3.24.10.3.1.

This octet(s) shall contain a User Defined Sound.

9.2.3.24.10.1.4 Predefined Animation

The Information‑Element‑Data octet(s) shall be coded as follows:

Octet 1 position indicating in the SM data the instant the animation shall be displayed. Set to the number of
characters from the beginning of the SM data after which the animation shall be displayed.

Octet 2 animation number. Shall be encoded as an integer value.

9.2.3.24.10.1.5 Large Animation

The Information‑Element‑Data octet(s) shall be coded as follows:

Octet 1 position indicating the instant the animation shall be displayed in the SM data
(refer clause 9.2.3.24.10.1.4).

Octet 2-n Protocol Data Unit as described in clause 9.2.3.24.10.3.3.

This octet(s) shall contain a Large Animation.

9.2.3.24.10.1.6 Small Animation

The Information‑Element‑Data octet(s) shall be coded as follows:

Octet 1 position indicating the instant the animation shall be displayed in the SM data
(refer clause 9.2.3.24.10.1.4).

Octet 2-n Protocol Data Unit as described in clause 9.2.3.24.10.3.3.

This octet(s) shall contain a Small Animation.

9.2.3.24.10.1.7 Large Picture

The Information‑Element‑Data octet(s) shall be coded as follows:

Octet 1 position indicating in the SM data the instant the picture shall be displayed. Set to the number of
characters from the beginning of the SM data after which the picture shall be displayed. This octet shall be coded as an integer value in the range 0 (beginning of the SM data) to the maximum number of characters included in the SM data of one single SM or one segment of a concatenated SM.

Octet 2-n Protocol Data Unit as described in 9.2.3.24.10.3.2.

This octet(s) shall contain a Large Picture.

9.2.3.24.10.1.8 Small Picture

The Information‑Element‑Data octet(s) shall be coded as follows:

Octet 1 position indicating in the SM data the instant the picture shall be displayed in the SM data
(refer clause 9.2.3.24.10.1.7).

Octet 2-n Protocol Data Unit as described in clause 9.2.3.24.10.3.2.

This octet(s) shall contain a Small Picture.

9.2.3.24.10.1.9 Variable Picture

The Information‑Element‑Data octet(s) shall be coded as follows:

Octet 1 position indicating in the SM data the instant the picture shall be displayed in the SM data
(refer clause 9.2.3.24.10.1.7).

Octet 2 Horizontal dimension of the picture.

This octet shall contain the horizontal number of 8 pixels i.e. this value shall be multiplied by 8 to get the whole number of horizontal pixels.

Octet 3 Vertical dimension of the picture.

This octet shall contain the vertical number of pixels.

Octet 4-n Protocol Data Unit as described in clause 9.2.3.24.10.3.2.

This octet(s) shall contain a Variable Picture line by line from top left to bottom right.

The values of the horizontal and vertical dimensions must be chosen properly by the sending entity. If the calculated size of this IE exceeds the limits of a single SM or segment it shall be discarded by the receiving entity.

Examples of EMS coding

All IE values in the TP-UD are hexadecimal values.

9.2.3.24.10.1.10 User Prompt Indicator

With the User Prompt Indicator a sending entity is able to indicate to the receiving entity, that the following object is intended to be handled at the time of reception, e.g. by means of user interaction. The object may be a picture, an animation, a User Defined Sound or a combination of these.

For example the User Prompt Indicator may be used when sending an operators logo to the ME that should be displayed instead of the operators name in standby mode.

When receiving the object the user shall be prompted to accept or discard the object. After this user interaction the SM may be discarded.

The User Prompt Indicator IE shall immediately precede the corresponding object IE(s).

If a User Prompt Indicator IE is not followed by a corresponding object IE it shall be discarded.

The Information‑Element‑Data octet(s) shall be coded as follows:

Octet 1 Number of corresponding objects.

This octet shall contain the number of corresponding objects as an integer value.

Where Octet 1 indicates that the User Prompt Indicator refers to more than one object, the ME should check the validity of the objects referenced for stitching together. The objects should be considered for stitching if they are either Images (Small, Large, Variable Pictures) or User Defined Sounds, and all of the objects referenced by the User Prompt Indicator IE are of the same type. Animations, Text formatting and pre-defined sound IE’s are not suitable for stitching.

User defined sounds may be stitched by concatenating the data contained within each User Defined Sound IE into a single melody object, this may be achieved by ignoring the iMelody header and footer information of the second and subsequent User Defined Sound IE’s referenced from the User Prompt Indicator.

Images may be joined along their vertical edges, to form a single "wide" image, the resulting image will have a width equal to the sum of the widths of all the images defined in the User Prompt Indicator.

9.2.3.24.10.1.11 Standard WVG Object

The Standard WVG object as defined by IEI 18 is structured as follows:

Octet 1 position indicating in the SM data the instant the object shall be displayed in the SM data

Octet 2..n Standard WVG object bit stream

The unused bits in the last octet will be filled with 0

The detailed data format and attributes of Standard WVG object are defined in Annex G.

The bit order is defined as follows:

The octet with a smaller octet number stores the bits appearing in the front position in the bit stream; the most significant bit in an octet stores the first bit in position in a 8-bit segment in the bit stream.

A Standard WVG object may or may not have fixed size. In either case, display size should be determined by the terminal implementation. Recommended display size is a largest possible size on terminal screen while aspect ratio shall be maintained.

9.2.3.24.10.1.12 Character Size WVG Object

The Character Size WVG object as defined by IEI 19 is structured as follows:

Octet 1 position indicating in the SM data the instant the object shall be displayed in the SM data

Octet 2..n Character Size WVG bit stream

The unused bits in the last octet will be filled with 0

The detailed data format and attributes of Character Size WVG object are defined in Annex G.

The bit order is defined as follows:

A Character Size WVG object is a small graphics similar to the size of a typed character. The display height for a Character Size WVG object is decided by the terminal implementation. Recommended Character Size WVG object height is to be similar to the message text font height. The width of a Character Size WVG object is variable depending on the aspect ratio defined in the object. Character Size WVG objects can appear more than one time in one message.

Example:

Dad, I you!

In the above example, the “heart” is a Character Size WVG object at the position in between the letter “I” and “y”.

In the above example, there are 4 Character Size WVG objects, each representing a Chinese character.

9.2.3.24.10.1.13 Extended Object

The Extended Object allows an extended code range for format types. The Extended Object may extend across segment boundaries of a concatenated short message. Octets 1 through 7 of the first Extended Object IE shall be contained in a single segment. A single segment may include one or more Extended Object IEs.

If multiple SMs are concatenated and at least one of them contains an Extended Object information element, then concatenation of the SMs shall be done using the ‘Concatenated short messages, 16-bit reference number’, verses the ‘Concatenated short messages, 8-bit reference number’ information element. The re-assembly of the Extended Object segments shall be done according to the sequence number of the associated Concatenation IE.

One or more Extended Objects may be compressed using a compression algorithm as indicated in the Compression Control IE (see clause 9.2.3.24.10.1.13).

An SME implementing the Extended Object IE shall be capable of interpreting an uncompressed concatenated message composed of at least min_eo_msg short messages which have been received. According to current content provider requirements and handset manufacturer constraints, variable min_eo_msg is set to 8.

The first Extended Object IE of an Extended Object contains a reference number, length, control data, type and position. The subsequent Extended Object IEs shall only contain Extended Object data as illustrated in Figure 9.2.24.10.11.

The IE length is variable.

Octet 1 Extended Object reference number.
A modulo 256 counter indicating the reference number for the Extended Object. Two different Extended Objects in a single concatenated message shall have different reference numbers.

Octet 2..3 Extended Object length in number of octets (integer representation) as shown in Figure 9.2.3.24.10.1.11.

Octet 4 Control data.

Bit 0 Object distribution

0 Object may be forwarded

1 Object shall not be forwarded by SMS

Bit 1 User Prompt Indicator

0 Object shall be handled normally
1 Object shall be handled as a User Prompt (see 9.2.3.24.10.1.10)

Bit 2..7 reserved

Any reserved values shall be set to 0.

Octet 5 Extended Object Type.
This octet indicates the format of the Extended Object from the table below.
If the value is reserved or if the associated format is not supported then the receiving entity shall ignore the Extend Object.

Format Type	Format Description
0x00	Predefined sound as defined in annex E.
0x01	iMelody as defined in annex E.
0x02	Black and white bitmap as defined in annex E.
0x03	2-bit greyscale bitmap as defined in annex E.
0x04	6-bit colour bitmap as defined in annex E.
0x05	Predefined animation as defined in annex E.
0x06	Black and white bitmap animation as defined in annex E.
0x07	2-bit greyscale bitmap animation as defined in annex E.
0x08	6-bit colour bitmap animation as defined in annex E.
0x09	vCard as defined in annex E.
0x0A	vCalendar as defined in annex E.
0x0B	Standard WVG object as defined in annex E
0x0C	Polyphonic melody as defined in annex E.
0x0D.. 0xFE	Reserved
0xFF	Data Format Delivery Request as defined in annex E.

Octet 6..7 Extended Object Position (integer representation).
The Extended Object Position indicates the absolute character position within the message text after which the object shall be played or displayed. The absolute character position relates to the entire text within the concatenated message, the first character is numbered character 1.

NOTE: Although this is an absolute value, for concatenated messages, it is suggested the positions used are those that lie within the text of short message segments that have the sequence number equal to or higher than the one that contains the Extended Object IE.

If more than one Extended Object is located at the same position then they may be played or displayed in sequence or simultaneously.

Octet 8..n Extended Object Data.
This sequence of octets is structured as illustrated in the figure below and defined annex E. This figure illustrates the construction of a number of SMs containing a large Extended Object which crosses a SM boundary and is encoded into 2 SM TPDUs. The figure illustrates only the User Data field of the SM (TPDUs). For a description of concatenation of SM refer to Figures 9.2.3.24 (a, b and c)

Figure 9.2.3.24.10.1.13

9.2.3.24.10.1.14 Reused Extended Object

This facility is used to reuse an Extended Object in a message which has already been defined in the same message.

Octet 1 Reference number of the Extended Object to be reused.

NOTE: The suggested reference numbers are those of Extended Objects that are contained in short messages that have the sequence number equal to or lower than the one that contains the Reused Extended Object IE.

Octet 2..3 indicates in the concatenated message the absolute character position after which the object shall be played or displayed.

NOTE: Although this is an absolute value, for concatenated messages, the suggested positions that lie within the text of short message segments that have the sequence number equal to or higher than the one that contains the Extended Object IE.

9.2.3.24.10.1.15 Compression Control

This information element is used to indicate a compressed octet sequence. The compression control is only used in association with one or more Extended Objects and/or Reused Extended Objects. The compressed data may extend across sequential short messages within a concatenated short message as illustrated by Figure 9.2.24.10.1.15. The first Compression Control IE of a compressed data sequence contains one octet of Compression Information and a 2-octet length field.

The SME shall support decompression if the Extended Object IE is implemented. An SME implementing the Extending Object IE shall be capable of decompressing a received stream for which the original uncompressed information fits into 1 to min_eo_msg messages. An SME may be capable of decompressing a received stream for which the original uncompressed information fits into more than min_eo_msg short messages. Variable min_eo_msg is defined in clause 9.2.3.24.10.1.11.

The IE length is variable.

Octet 1 Compression information.

Bits 0..3 represent the compression algorithm and bits 4..7 represent compression algorithm specific parameters.

Bit 0..3 Compression algorithm

0000 LZSS Compression according to clause 9.2.3.24.10.1.15.1

Bit 4..7 Shall be set 0.

0001..1111 reserved for future use; reserved bits shall be transmitted 0.

Bit 4..7 reserved

Octets 2..3 Length of the compressed data in octets (integer representation).
The length indicates the length of the compressed data that may extend across several compression control IEs.

Octets 4..n Compressed data may contain one or more compressed Extended Objects. Figure 9.2.3.24.10.1.15 is an example and illustrates the assembly of a series of SM TPDUs from a sequence of concatenated and compressed extended objects. Each Extended Object is preceded by its IEI (Extended Object or Reused Extended Object). A series of Extended Objects is then compressed into a single buffer and this is split into several SM TPDUs as illustrated.

*E.O Means Extended Object.

*R.E.O means Reused Extended Object.

C.C. means compression.

Figure 9.2.3.24.10.1.15

9.2.3.24.10.1.15.1 LZSS Implementation for EMS extended object compression

LZSS compression uses two tokens to identify either literal strings (byte-sequences) or references to repeated sequences. These tokens (for EMS extended-object compression) are described in this clause of the document. A more general introduction to LZSS compression together with an informative example (based upon the tokens described below) is provided in Annex F (informative).

The compressed data stream consists of any combination of literal data blocks and slice descriptor sequences.

The format of the compressed data stream is illustrated as follows: –

Compressed data stream (initial section) …..
1	2	3	4	5	.	.	.	.	.	.	.	.	.
Literal data block							Slice descriptor		Literal data block				Slice descriptor	Slice descriptor

Figure 9.2.3.24.10.1.15.1.a LZSS compressed data format

This diagram represents the structure of a compressed byte stream using LZSS. The stream contains a mixture of literal octets from the input buffer and slice descriptors representing the re-occurrence of an octet sequence together with a length and index for the matching octet sequence. The initial octets of a compressed buffer will always be a sequence of literal octets. The structures of the literal data blocks and slice descriptors are given below.

Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
1	Number literal bytes to follow.

Figure 9.2.3.24.10.1.15.1.b Literal block identifier

When literal octets are written into the compression buffer (for instance during the initial phases of compression) they are preceded by a literal block identifier. The most significant bit (bit 7) of this block shall be set 1. Bits 6-0 indicate the length of the literal block which follows (up to 127 octets). If no match can be found in an octet sequence of greater that 127 octets then 2 (or more) literal blocks shall be written sequentially.

Octet 1

Octet 2

Bit 15

Bit 14

Bit 13

Bit 12

Bit 11

Bit 10

Bit 9

Bit 8

Bit 7

Bit 6

Bit 5

Bit 4

Bit 3

Bit 2

Bit 1

Bit 0

Slice Length

Slice Offset

Figure 9.2.3.24.10.1.15.1.c Slice Descriptor

As can be seen from the above table, the slice descriptor sequence length is two octets, hence only repeating slices of data longer than two octets are extracted. The “slice length” is contained in the descriptor high octet and describes a data slice length of up to 63 octets. The “slice offset index” to the start of the slice is contained in the lower 9 bits and limits the window to 511 octets. The “slice offset index” gives the start position of the source slice measured backwards from the current writing position in the output decoded message data buffer, expressed as a positive number.

9.2.3.24.10.1.15.2 Data Compression

The compressed data output stream is constructed by repeating the following process until the end of the input data buffer is reached.

The input data buffer is scanned, from the current reading position (minus 1) through to a position 511 bytes back from current reading position (the window) looking for the maximum (but limited to 63 octets) length matching data slice contained that matches the data starting at the current reading position (the look ahead buffer).

If no matching data slice, longer than two octets, is found then the input data octet at the current reading position is written to a literal buffer. Both the current reading position in the input data buffer and the current writing position in the output data buffer are incremented by one.

If a matching slice is found then a slice descriptor is written to the output data buffer at the current writing position in the output data buffer and the current writing position is incremented by two. The current reading position in the input data buffer is incremented by the length of the newly found matching data slice.

If the next read octet results in a matching slice being found then the literal buffer is written out. The literal block header, containing a count of the number of literals in the block, is written out first. (If more than 127 literal octets exist in the literal buffer, then it is split into multiple blocks).

The above sequence is repeated until the current reading position reaches the end of the input data buffer.

When encoding (compressing), it is the input data buffer, up to the current reading position, that is used to search for already known matching data slices, as this represents, and is equal to, the reconstructed output data buffer of the decoder at the receiving end.

9.2.3.24.10.1.15.3 Data De-compression

The following sequence is repeated until the end of the input data buffer.

The data octet at the current reading position in the input data buffer is tested for either 0 or 1 in bit 7.

If the bit is set (bit 7 = 1), then the number of literal octets that follow is determined from the lower 7 bits of the header octet (this one).

The literal octet block is written to the output data buffer at the current writing position and both the output data writing position and the input data reading position pointers are incremented by the block size.

If the bit is clear (bit 7 = 0), then the “slice length” and “slice offset index” are extracted from the two octet slice descriptor.

The data slice is copied from within the output data buffer to the end of the output data buffer, where the start of the source slice is at a position “slice offset index” back from the current output data writing position and the destination start position of the slice is the current output buffer writing position. The input data buffer reading position is incremented by two and the output data writing position is incremented by the “slice length”.

9.2.3.24.10.1.15.4 Test Vectors

In order to assist implementers of the compression algorithm described in this specification, a suite of test vectors and ‘help’ information are available in electronic format. The test vectors are supplied with this specification.

These test vectors provide checks for most of the commonly expected parameter value variants in this specification and may be updated as the need arises.

In addition Annex F contains an introduction to LZ-type compression algorithms and also has a brief informative example.

9.2.3.24.10.1.16 Object Distribution Indicator

This facility allows a level of control to be requested over the distribution of objects contained within selected information elements in short messages.

If no Object Distribution Indicator is specified for an information element in which an object is received, then that object may be freely distributed.

If a MS provides facilities to modify an object, then the Distribution Attributes (see below) shall be maintained; i.e. an object that is not allowed to be distributed cannot become so after modification.

The use of the Object Distribution Indicator in conjunction with a TE is beyond the scope of the present document.

Where the Object Distribution Indicator is applied to object IE’s that are also addressed by an IE which affects or controls them in some other way (such as User Prompt Indicator IE (see clause 9.2.3.24.10.1.10)), then it shall precede all of the IE’s including the other controlling IE’s.

Octet 1 Number of Information Elements.

This octet specifies the number of information elements from 1-255 for which the Distribution Attributes in the next octet shall apply. The affected objects shall be contained in Information Elements immediately following this IE and may be contained in subsequent short message segments within a concatenated short message.

If the Object Distribution Indicator is applied to the same object IE’s as addressed by an IE which affects or controls them in some other way (such as the User Prompt Indicator IE), then value of this field shall reflect the total number of all the object IE’s and all of the controlling IE’s.

If set to 0 the Distribution Attributes shall apply to all information elements until either the end of the message or another Object Distribution Indicator IE is received.

Octet 2 Distribution Attributes.

Bit 0

0 the associated object(s) may be forwarded

1 the associated object(s) shall not be forwarded by SMS

bit 1..7

reserved for future use.

9.2.3.24.10.1.17 Reply Address Element

Only one alternate Reply Address Element can be integrated in a message. In the case the Reply Address Element is part of a Concatenated SM this IE shall occur in its first segment only.

Octet 1..n Alternate Reply Address encoded as specified for address fields in clause 9.1.2.5

When this IE is received in a message, replies to this message should take place by default using the address specified in this IE instead of the regular message TP-OA.

NOTE: Despite the fact that MMI aspects of the ME are out of the scope of the present document, it must be mentioned that this mechanism might open the door to potential abuse. It is desirable that the user is made aware in some way that the reply address of the incoming message is different from the originator’s one, and that the user is presented with the original TP-OA address to identify the sender of the SM .

9.2.3.24.10.1.18 Extended Object Data Request Command

There is no data element associated with this IE. The associated Information Element Length field is present but set to zero.

Upon receiving this IE in an SMS-DELIVER PDU, if an MS supports this request and the corresponding response, it shall respond with an SMS-DELIVER-REPORT PDU containing a Data Format Delivery Request as defined in the Extended Object IE. This SMS-DELIVER PDU may be discarded.

9.2.3.24.10.2.1 Example of Basic text formatting and predefined EMS coding

An example of the basic concept of coding is given as follows:

TP-UDHI=1

SMS User Data Header: UDHL=05, IEI=0A, IEDL=03, IED₁=0F, IED₂=12, IED₃=10

SMS User Data: This is a text with bold option on following with normal text.

Should be displayed as:

This is a text with bold option on following with normal text.

It is also possible to add predefined sounds in the message.

Example:

TP-UDHI=1

SMS User Data Header: UDHL=08, IEI=0B, IEDL=02, IED₁=09,<sound5>, IEI=0B, IEDL=2, IED₁=1C,
<sound7>

SMS User Data: This is a message with two different sounds.

The sound nr5 shall be played after the 9^th received character ("a") and sound nr7 shall be played after the 28^th received character ("e").

9.2.3.24.10.2.2 Example of User defined Objects EMS coding

Example of a message including one small picture is coded as follows:

TP UDHI=1

SMS User Data Header: UDHL=24, IEI=11, IEIDL=22, IED₁=08, < (small picture 32bytes)>

SMS User Data: Hello!<CR><LF><CR><LF>One small picture in here

Should be displayed as:

Hello!

One small picture in here

If the message starts with <CR>, then the "unreadable" data in an old terminal will be overwritten by the text, and the user will not see any strange characters. It is possible to insert the same picture several times in the same message. In that case, the TP-UD header shall contain as many IE as the number of occurrences contained in the SM or one segment of a concatenated message. Using defined elements will normally imply that more than one SM is required and therefore concatenation is required.

9.2.3.24.10.2.3 Concatenation of SMS messages

Concatenated messages are required in most cases required when using several types of EMS elements, since it is only possible to send one large picture/large animation/melody in one single SM. After including either of these elements, there are only 4 (or 9 if no concatenation is used) characters left to the text part, and this is usually too little.

If one or more objects are embedded in one segment of a concatenated message, the IE octet indicating its/their position within the SM data cannot be set to a value that would refer to a position in the next segment(s) so that received segments should be processed before all of them have been received. It means that a formatting text that could not be conveyed in one segment shall be split in as many segments as necessary. In that case, the IE relating to the formatting shall be repeated in all the segments in which it will apply.

Example of a message including 2 Large Pictures, 4 Small animations and 2 User defined Melodies together with some text.

The EMS message: <Large Picture1> <User Defined Melody 1> Hello All, This is a real Enhanced Message <Small Animation 1>. I can send <Small Animation 2> and receive <Small Animation 3> really advanced EMS messages <Animation 4> Isn’t it impressive? /Lars <User Defined Melody2> <Large Picture 2>

This EMS message has to use concatenated messages and the SM will typically contain the following data:

SM	User Data Header	User Data
1	IEI=10 (Large Picture) IED₁=00 (beginning of the SM) <Large Picture 1 (128 bytes)>	[<CR><LF>]
2	IEI=0C (User Defined Sound) IED₁=00 (beginning of the SM) <User Melody 1 (129bytes max)>	Hello
3	IEI=0F (Small Animation) IED₁=24 (36^th position) <Small Animation 1 (32 bytes)> IEI=0F (Small Animation) IED₁=2F (47^th position) <Small Animation 2 (32 bytes)>	All, This is a real Enhanced Message. I can send and
4	IEI=0F (Small Animation) IED₁=07 (7^th position) <Small Animation 3 (32 bytes)> IEI=0F (Small Animation) IED₁=25 (37^th position) <Small Animation 4 (32 bytes)>	receive really advanced EMS messages. Isn’t it impressive? /Lars.
5	IEI=0C (User Defined Sound) IED₁=00 (beginning of the SM) <User Melody 1 (128 bytes max)>	[<CR><LF>]
6	IEI=10 (Large Picture) IED₁=00 (beginning of the SM) <Large Picture 2 (128 bytes)>

9.2.3.24.10.3 EMS Formats

9.2.3.24.10.3.1 Sounds

Predefined Sounds

There are a number of fixed predefined sounds. Each sound nr corresponds to a specific sound according to the table below. The presentations of these sounds are manufacturer specific.

Sound nr	Description
0	Chimes high
1	Chimes low
2	Ding
3	TaDa
4	Notify
5	Drum
6	Claps
7	FanFar
8	Chord high
9	Chord low

User defined sounds

The user defined sounds are coded according to the iMelody format[33]. The maximum length of a sound is 128 bytes.

9.2.3.24.10.3.2 Pictures

Pictures are coded from upper left to lower right and in each byte the most significant bit represent the pixel at the left. The pictures are plain black and white, no colours or grey scales are supported. The bitvalue "0" represents a white pixel and the bitvalue "1" represents a black pixel.

Example 16*16 picture

Byte 1	Byte 2
Byte 3	Byte 4
…	…
…	…
Byte 31	Byte 32

9.2.3.24.10.3.3 Animation

Predefined

There are a number of predefined animations. Each animation nr corresponds to a specific animation according to the table below. The way of displaying the animation is manufacturer specific.

Animation nr	Description
0	I am ironic, flirty
1	I am glad
2	I am sceptic
3	I am sad
4	WOW!
5	I am crying
6	I am winking
7	I am laughing
8	I am indifferent
9	In love/Kissing
10	I am confused
11	Tongue hanging out
12	I am angry
13	Wearing glasses
14	Devil

User Defined

Animations are coded as 4 sequential pictures, with the first picture sent first.

9.2.3.24.11 IETF RFC 5322 E-Mail Header

This information element is used to indicate the existence of an IETF RFC 5322 Internet electronic mail in the data part of the short message. Both, E-Mail Header and (optional) E-Mail Body shall be parts of the SM’s data and shall be compliant with the syntax specified in IETF RFC 5322 [34]. The character set used for encoding of E-Mail Header and E-Mail body, however, shall be according to 3GPP TS 23.038 [9]. Encoding of E-Mail Header and E-Mail Body shall be done using the same character set.

In compliance with IETF RFC 5322 [34] the E-Mail Header shall always be located at the very beginning of the SM’s data part. It shall always be present in the "unfolded" format as it is specified in IETF RFC 5322 [34]. Not the <CRLF> character defined in IETF RFC 5322 [34] but the <LF> character according to 3GPP TS 23.038 [9] shall be used for the separation of different E-Mail Header fields.

If an RFC 5322 E-Mail Body exists, it shall immediately follow the E-Mail Header in the SM’s data part.

NOTE 1: The null line defined in IETF RFC 5322 [34] for the separation of E-Mail Header and E-Mail Body may be discarded.

NOTE 2: The sending of extended SMTP headers is allowed and the MS should not reject the message if there are header fields in the email header part that are not specified in IETF RFC 5322 [34].

In case of an IETF RFC 5322 [34] E-Mail Header exceeding the data part of a single SM, concatenation shall be used. In this case the E-Mail Header starts in the first segment of a concatenated SM and continues in one or several subsequent segments. The IETF RFC 5322 [34] E-Mail Body shall immediately follow the final fraction of the IETF RFC 5322 [34] E-Mail Header and may also be spread over several segments of the concatenated SM.

In case where this IEI is to be used in a concatenated SM then the IEI, its associated IEDL, and IED fields shall be contained in the first segment of the concatenated SM and shall also be contained in every subsequent segment of the concatenated SM.

The Information‑Element‑Data octet shall be coded as follows:

Octet 1 IETF RFC 5322[34] E-Mail Header length indicator.

This octet shall indicate the length of the IETF RFC 5322 [34] E-Mail Header that is located at the beginning of the data part of the SM. In case of an E-Mail Header exceeding the data part of a single SM, this octet shall indicate the length of that fraction of the IETF RFC 5322 [34] E-Mail Header that is located at the beginning of the data part of the current segment of the concatenated SM.

If the user data is coded using the GSM 7 bit default alphabet, this IED octet shall give an integer representation of the number of septets within (that fraction of) the IETF RFC 5322 [34] E-Mail Header that is located at the beginning of the data part of the current (segment of the concatenated) SM. See figure 9.2.3.24.11 (a).

If the user data is coded using 8‑bit data, this IED octet shall give an integer representation of the number of octets within (that fraction of) the IETF RFC 5322 E-Mail Header that is located at the beginning of the data part of the current (segment of the concatenated) SM. See figure 9.2.3.24.11 (b).

If the user data is coded using UCS2 [24] data, this IED octet shall give an integer representation of the number of UCS2 characters (consisting of 2 octets) within (that fraction of) the RFC 822 E-Mail Header that is located at the beginning of the data part of the current (segment of the concatenated) SM. See figure 9.2.3.24.11 (c).

NOTE 3: If the user data is coded using compressed GSM 7 bit default alphabet or compressed 8 bit data or compressed UCS2 [24] data the RFC 822 E-Mail Header length indicator’s value shall be based on the amount of uncompressed data, i.e. before compression is performed.

The diagram below shows the layout of the IED for GSM 7 bit default alphabet data.

Figure 9.2.3.24.11 (a)

The diagram below shows the layout of the IED for 8 bit data.

Figure 9.2.3.24.11 (b)

The diagram below shows the layout of the IED for UCS2 data.

Figure 9.2.3.24.11 (c)

9.2.3.24.12 Hyperlink format element

A hyperlink format element shall be structured as follows:

Octet 1 and 2 Absolute Element Position (integer representation).

The Absolute Element Position indicates the absolute character position within the message text. The absolute character position relates to the entire text within the concatenated message, the first character is numbered character 1.

Octet 3 Hyperlink Title length: an integer representation of the number of characters in the hyperlink title.

Octet 4 URL length: an integer representation of the number of characters in the URL.

A space character shall be inserted between the hyperlink title and the URL. The hyperlink title can be a mixture of text, animations and pictures. Elements (text, animations and pictures) for which the position is included in the range [Absolute hyperlink position…Absolute hyperlink position+hyperlink title length] are part of the hyperlink title. The string of text in the range [Absolute hyperlink position+hyperlink title length+1…Absolute hyperlink position+hyperlink title length+1+URL length] is to be interpreted as a URL.

9.2.3.24.13 Enhanced Voice Mail Information

Enhanced Voice Mail Information allows a Voice Mail system to convey to a mobile subscriber, comprehensive information regarding individual voice mail messages and mailbox status.

Enhanced Voice Mail Information has two types of Information Element Data

– Enhanced Voice Mail Notification which conveys to the MS information regarding newly deposited Voice Mail messages and Voice Mailbox Status

– Enhanced Voice Mail Delete Confirmation which allows an MS to maintain Voice mailbox status information synchronisation between the MS and the Voice Mailbox in the event of Voice Mail Message deletion.

The first ‘bit’ of the Enhanced Voice Mail Information Element Data is known as Enhanced Voice Mail PDU Type and discriminates between whether the Enhanced Voice Mail Information PDU is an Enhanced Voice Mail Notification or an Enhanced Voice Mail Delete Confirmation.

9.2.3.24.13.1 Enhanced Voice Mail Notification

The Enhanced Voice Mail Notification Information Element Data has the following format where the parameters are in strict order following the IEDL. The Enhanced Voice Mail Notification IEI and its associated IEDL and IED shall be complete within a single UDH.

In the event of a contradiction between Enhanced Voice Mail Notification and either the DCS (23.038) [9] indicating Voicemail Message Waiting or the Special SMS Message Indication (9.2.3.24.2) indicating Voice Message Waiting or both then the Enhanced Voice Mail Notification specified here shall take precedence.

Parameter	Parameter Length	Mandatory/Optional/Conditional
ENHANCED_VOICE_MAIL_PDU_TYPE	Bit 0 Octet 1	M
RESERVED_FOR_FUTURE_USE	Bit 1 Octet 1	M
MULTIPLE_SUBSCRIBER_PROFILE	Bits 2..3 Octet 1	M
SM_STORAGE	Bit 4 Octet 1	M
VM_MAILBOX_ALMOST_FULL	Bit 5 Octet 1	M
VM_MAILBOX_FULL	Bit 6 Octet 1	M
VM_MAILBOX_STATUS_EXTENSION_INDICATOR	Bit 7 Octet 1	M
VM_MAILBOX_ACCESS_ADDRESS	Octets 2… n+2 (NOTE 2)	M
NUMBER_OF_VOICE_MESSAGES	Bits 0..7 Octet n+3	M
NUMBER_OF_VM_NOTIFICATIONS	Bits 0..4 Octet n+4	M
RESERVED_FOR_FUTURE_USE	Bits 5..7 Octet n+4	M
VM_MAILBOX_STATUS_EXTENSION_LENGTH	1 Octet (NOTE 3)	C
VM_MAILBOX_STATUS_EXTENSION_DATA	1 or more Octets (NOTE 3)	C
VM_MESSAGE_ID (NOTE 1)	Bits 0..15 Octets n+5..n+6	M
VM_ MESSAGE_LENGTH (NOTE 1)	Bits 0..7 Octet n+7	M
VM_ MESSAGE_RETENTION_DAYS (NOTE 1)	Bits 0..4 Octet n+8	M
RESERVED_FOR_FUTURE_USE (NOTE 1)	Bit 5 Octet n+8	M
VM_MESSAGE_PRIORITY_INDICATION (NOTE 1)	Bit 6 Octet n+8	M
OCTET_VM_MESSAGE_EXTENSION_INDICATOR (NOTE 1)	Bit 7 Ocet n+8	M
VM_MESSAGE_CALLING_LINE_IDENTITY (NOTE 1)	Octets n+9.. n+9+m (NOTE 2)	M
VM_MESSAGE_EXTENSION_LENGTH (NOTE 1)	1 Octet (NOTE 3)	C
VM_MESSAGE_EXTENSION_DATA (NOTE 1)	1 or more Octets (NOTE 3)	C
NOTE 1: This sequence of parameters are repeated a number of times according to the number of Voice Mail notifications conveyed in this IE. NOTE 2: ‘n’ and ‘m’ denote the number of octets required for the VM_MAILBOX_ACCESS_ADDRESS and the VM_CALLING_LINE_IDENTITY as appropriate including the Address-Length, Type-of-address and Address-value (see 9.1.2.5). NOTE 3: The Conditional Octets are excluded from the Octet count in the table in this release because no extensions are defined in this release.

ENHANCED_VOICE_MAIL_PDU_TYPE This parameter shall be set to 0 to specify that the following Information Element Data Parameters is an Enhanced Voice Mail Notification.

RESERVED_FOR_FUTURE_USE This parameter is set to 0 and is reserved for future use.

MULTIPLE_SUBSCRIBER_PROFILE This parameter shall indicate the Multiple Subscriber Profile (see 3GPP TS 23.097 [41]):

00 profile ID 1

10 profile ID 2

01 profile ID 3

11 profile ID 4

SM_STORAGE This parameter shall be set to 0 to indicate that this SM shall be discarded after evaluating its contents; otherwise it shall be set to a 1 to indicate to the MS that this SM shall be stored in the ME or the USIM.

VM_MAILBOX_ALMOST_FULL This parameter shall be set to 1 if the Voice Mailbox in the Voice Mail system is almost full; otherwise this field shall be set to 0. The point at which the voice mailbox is considered almost full is Voice Mail System specific.

VM_MAILBOX_FULL This parameter shall be set to 1 if the Voice Mailbox in the Voice Mail system is full; otherwise this field shall be set to 0.

VM_MAILBOX_STATUS_EXTENSION_INDICATOR In this release, this parameter shall be set to 0. This parameter shall be set to 1 to indicate that a VM_MAILBOX_STATUS_EXTENSION_LENGTH parameter is present in this PDU.

VM_MAILBOX_ACCESS_ADDRESS This parameter shall contain the Voice Mailbox number. It shall be coded according to section 9.1.2.5. In case of contradiction between this parameter and the Mailbox Dialing Numbers stored on (U)SIM this parameter shall take precedence and the MS may try to update EF_MBDN on (U)SIM.

NUMBER_OF_VOICE_MESSAGES This octet shall contain a value in the range 0 to 255 indicating the current number of Voice Mail messages that are unread. The value 255 shall be taken to mean 255 or greater. The NUMBER_OF_VOICE_MESSAGES shall be stored on the (U)SIM in accordance with the procedure for storage of Message Waiting Indication Status described in Special SMS Message Indication (9.2.3.24.2).

NUMBER_OF_VM_NOTIFICATIONS This parameter has a range 0 to 15. This parameter shall indicate the number of specific Voice Message notifications to follow within this IE.

RESERVED_FOR_FUTURE_USE This parameter shall be set to 0 and is reserved for future use.

VM_MAILBOX_STATUS_EXTENSION_LENGTH This parameter shall be set to the number of additional octets that immediately follow. This parameter has a value in the range 0 to 255. The presence of this parameter is conditional on the setting of VM_MAILBOX_STATUS_EXTENSION_INDICATOR in this PDU.

VM_MAILBOX_STATUS_EXTENSION_DATA This parameter comprises a number of additional octets allowing additional VM mailbox generic status parameters to be conveyed in this PDU. Additional octets are not defined in this release but may be defined later by 3GPP. This parameter is conditional on the presence of VM_MAILBOX_EXTENSION_LENGTH

VM_MESSAGE_ID This parameter shall be set to the message ID of the Voice Mail message in this specific Voice Message notification. This parameter is binary and has a range 0 to 65535, modulus 65536. It is the responsibility of the Voice Mail system to set this parameter to uniquely identify a Voice Mail message within the modulus.

VM_ MESSAGE_LENGTH This parameter shall be set to the length of the Voice Mail message in this notification in seconds. This parameter has a range 0 to 255. For voice mail messages that are longer than 255 seconds, this parameter shall be set to its maximum 255.

VM_ MESSAGE_RETENTION_DAYS This parameter shall be set to the number of days after which the specific Voice Mail message in this notification is anticipated to be automatically deleted from the Voice Mail system timed from the GSM Timestamp (TP-SCTS 9.2.3.11) for this Enhanced Voice Mail Notification. This parameter has a range 0 to 31. For Voice Mail messages that have a longer retention time than 31 days, this parameter shall be set to its maximum 31.

NOTE: The GSM Timestamp is the time that the SC received the SM from the Voice Mail system which is not necessarily the time that the voice message was deposited into the Voice Mail system.

RESERVED_FOR_FUTURE_USE This parameter is set to 0 and is reserved for future use.

VM_ MESSAGE_PRIORITY_INDICATION This parameter shall be set to 1 to indicate that the specific Voice Mail message in this notification held in the Voice Mailbox is urgent; otherwise the parameter shall be set to 0.

VM_MESSAGE_EXTENSION_INDICATOR In this release, this parameter shall be set to 0. This parameter shall be set to a 1 to indicate that a VM_MESSAGE_EXTENSION_LENGTH parameter is present in this PDU.

VM_MESSAGE_CALLING_LINE_IDENTITY This parameter shall contain the address to be used by the mobile subscriber to contact the originator of the specific Voice Mail message in this notification. Where the CLI is not available then the coding of this parameter shall indicate that there is no address. i.e The length indicator in this parameter shall be set to 0.

This parameter coding shall comply with the the SM-TL address format specified in 9.1.2.5 above.

VM_MESSAGE_EXTENSION_LENGTH This parameter shall be set to the number of additional octets that immediately follow. This parameter has a value in the range 0 to 255. The presence of this parameter is conditional on the setting of VM_MESSAGE_EXTENSION_INDICATOR in this PDU.

VM_MESSAGE_EXTENSION_DATA This parameter comprises a number of additional octets allowing additional voicemail message specific parameters to be conveyed in this PDU. Additional octets are not defined in this release but may be defined later by 3GPP. This parameter is conditional on the presence of VM_MESSAGE_EXTENSION_LENGTH.

9.2.3.24.13.2 Enhanced Voice Mail Delete Confirmation

The Enhanced Voice Mail Delete Confirmation Information Element Data contains synchronization information. A Voice Mail system may send an Enhanced Voice Mail Delete Confirmation in order to indicate to the ME that certain voice mail messages that have been deleted and to indicate the updated status of the Voice Mailbox.

The Enhanced Voice Mail Delete Confirmation Information Element Data has the following format where the parameters are in strict order following the IEDL. The Enhanced Voice Mail Delete Confirmation IEI and its associated IEDL and IED shall be complete within a single UDH.

Parameter	Parameter Length	Mandatory/Conditional/Optional
ENHANCED_VOICE_MAIL_PDU_TYPE	Bit 0 Octet 1	M
RESERVED_FOR_FUTURE_USE	Bit 1 Octet 1	M
MULTIPLE_SUBSCRIBER_PROFILE	Bits 3..2 Octet 1	M
SM_STORAGE	Bit 4 Octet 1	M
VM_MAILBOX_ALMOST_FULL	Bit 5 Octet 1	M
VM_MAILBOX_FULL	Bit 6 Octet 1	M
VM_MAILBOX_STATUS_EXTENSION_INDICATOR	Bit 7 Octet 1	M
VM_MAILBOX_ACCESS_ADDRESS	Octets 2..n+2 (NOTE 2)	M
NUMBER_OF_VOICE_MESSAGES	Bits 0..7 Octet n+3	M
NUMBER_OF_VM_DELETES	Bits 0..4 Octet n+4	M
RESERVED_FOR_FUTURE_USE	Bits 5..7 Octet n+4	M
VM_MAILBOX_STATUS_EXTENSION_LENGTH	1 Octet (NOTE 3)	C
VM_MAILBOX_STATUS_EXTENSION_DATA	1 or more Octets (NOTE 3)	C
VM_MESSAGE_ID (NOTE 1)	Octets n+5..n+6	M
RESERVED_FOR_FUTURE_USE (NOTE 1)	Bits 0..6 Octet n+7	M
VM_MESSAGE_EXTENSION_INDICATOR (NOTE 1)	Bit 7 Octet n+7	M
VM_MESSAGE_EXTENSION_LENGTH (NOTE 1)	1 Octet (NOTE 3)	C
VM_MESSAGE_EXTENSION_DATA (NOTE 1)	1 or more Octets (NOTE 3)	C
NOTE 1: This sequence of parameters are repeated a number of times according to the number of Voice Mail Delete Confirmations conveyed in this IE. NOTE 2: ‘n’ denotes the number of octets required for the VM_MAILBOX_ACCESS_ADDRESS including the Address-Length, Type-of-address and Address-value (see 9.1.2.5). NOTE 3: The Conditional Octets are excluded from the Octet count in the table in this release because no extensions are defined in this release.

ENHANCED_VOICE_MAIL_PDU_TYPE This parameter shall be set to 1 to specify that the following Information Element Data is an Enhanced Voice Mail Delete Confirmation.

RESERVED_FOR_FUTURE_USE This parameter is set to 0 and is reserved for future use.

MULTIPLE_SUBSCRIBER_PROFILE See clause 9.2.3.24.13.1

SM_STORAGE See clause 9.2.3.24.13.1

VM_MAILBOX_ALMOST_FULL See clause 9.2.3.24.13.1

VM_MAILBOX_FULL See clause 9.2.3.24.13.1

VM_MAILBOX_ACCESS_ADDRESS See clause 9.2.3.24.13.1

NUMBER_OF_VOICE_MESSAGES See clause 9.2.3.24.13.1

NUMBER_OF_VM_DELETES This parameter has a range 0 to 63. This parameter shall indicate the number of VM_MESSAGE_ID’s that follow in this IE

RESERVED_FOR_FUTURE_USE This parameter is set to 0 and is reserved for future use.

VM_MAILBOX_STATUS_EXTENSION_DATA This parameter comprises a number of additional octets allowing additional VM mailbox generic status parameters to be conveyed in the PDU. Additional octets are not defined in this release but may be defined later by 3GPP. This parameter is conditional on the presence of VM_MAILBOX_EXTENSION_LENGTH

VM_MESSAGE_ID This parameter shall be set to the message ID of the specific voice mail message(s) whose deletion is being confirmed. The range of this parameter is defined in clause 9.2.3.24.13.1 and for a specific voice mail message the value of this parameter shall be identical to that used for the VM Notification. This parameter is repeated according to the number of voice mail message deletions being confirmed.

RESERVED_FOR_FUTURE_USE This parameter is set to 0 and is reserved for future use. This parameter is repeated according to the number of voice mail message deletions being confirmed.

VM_MESSAGE_EXTENSION_INDICATOR In this release, this parameter shall be set to 0.This parameter shall be set to a 1 to indicate that a VM_MESSAGE_EXTENSION_LENGTH parameter is present in this PDU.

9.2.3.24.14 Identification of a directory number within the User Data Field

A directory number may, as an optional feature, be identified within the User Data Field.

This allows, for example, a receiving entity to automatically identify a string of digits in the User Data Field as being a telephone number in order to facilitate easy call back by user action.

This shall be implemented by enclosing the directory number in inverted commas (character 0100010 from the 7 bit default alphabet in 3GPP TS 23.038 [9] or its equivalent in other character sets).

Unspecified address formats or International address formats (using + symbol) may be used for the directory number.

Spaces may be included with the directory number inside the inverted commas. E.g. “+1 234 567 8901”

The User Data Field displayed to the recipient may contain more than one directory number, in which case it is for the user to select the one required.

9.2.3.24.15 National Language Single Shift

This information element is used to indicate which National Language Single Shift Table is used instead of the GSM 7 bit default alphabet extension table specified in 3GPP TS 23.038 [9].

The total length of the IE is 1 octet:

octet 1 National Language Identifier.

The National Language Identifier values and Language tables are defined in 3GPP TS 23.038 [9].

A receiving entity shall ignore (i.e. skip over and commence processing at the next information element) this information element if the value of the National Language Identifier is not described in 3GPP TS 23.038 [9].

If this IE is duplicated within different segments of a concatenated message then a receiving entity shall process each segment individually.

If this IE is not included within a segment of a concatenated message then the receiving entity shall use the GSM 7 bit default alphabet extension table for this segment.

In the event that this IE is duplicated within one segment of a concatenated message or a single message then a receiving entity shall use the last occurrence of the IE.

In the event that this IE is received within a single message or a segment of a concatenated message, in which the DCS has indicated UCS-2 encoding, then the receiving entity shall ignore this IE.

9.2.3.24.16 National Language Locking Shift

This information element is used to indicate which National Language Locking Shift Table is used instead of the GSM 7 bit default alphabet specified in 3GPP TS 23.038 [9].

This IE is coded in the same way as the National Language Single Shift IE in clause 9.2.3.24.15.

If this IE is duplicated within different segments of a concatenated message then a receiving entity shall process each segment individually.

If this IE is not included within a segment of a concatenated message then the receiving entity shall use the GSM 7 bit default alphabet table for this segment.

In the event that this IE is duplicated within one segment of a concatenated message or a single message then a receiving entity shall use the last occurrence of the IE.

In the event that this IE is received within a single message or a segment of a concatenated message, in which the DCS has indicated UCS-2 encoding, then the receiving entity shall ignore this IE.

9.2.3.25 TP‑Reject‑Duplicates (TP‑RD)

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 9.2.3.6..

9.2.3.26 TP‑Status‑Report‑Qualifier (TP‑SRQ)

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.

9.2.3.27 TP‑Parameter‑Indicator (TP‑PI)

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:

bit 7	bit 6	bit 5	bit 4	bit 3	bit 2	bit 1	bit 0
Extension bit	Reserved	Reserved	Reserved	Reserved	TP‑UDL	TP‑DCS	TP‑PID

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.

9.2.3.28 TP‑Loop-Prevention (TP‑LP)

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.

TP-LP Value	Description
0	The message has not been forwarded and is not a spawned message (or the sending network entity (e.g. an SC) does not support the setting of this bit.)
1	The message has either been forwarded or is a spawned message.