Content for  TS 23.040  Word version:  18.0.0

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

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. The IEI and associated IEI length and IEI data shall be present in every segment of the concatenated SM.

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 TS 23.038) 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 TS 51.011) or USIM (see TS 31.102) when present or otherwise should be stored in the ME. In case there are multiple records of EFMWIS 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: 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: 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.

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: The port range is up to 255 using 8 bit addressing space. The Integer value of the port number is presented as in 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.

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 4 octets: The port range is up to 65535 using 16 bit addressing space. The Integer value of the port number is presented as in 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.

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.

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:

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

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. 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 (TS 23.042) shall immediately precede the Security Header.

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 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-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: The IEI and associated IEI length and IEI data shall be present in every segment of the concatenated SM.

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