Content for  TS 23.040  Word version:  19.0.0

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.

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.

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.

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.

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 clause 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:

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.