2 SMS Block Mode

07.053GPPTSUse of Data Terminal Equipment - Data Circuit Terminating Equipment (DTE-DCE) Interface for Short Message Services (SMS) and Cell Broadcast Services (CBS)

2.1 Beginning and ending of SMS/CBS Block Mode

2.1.1 Beginning SMS/CBS Block Mode

As described in GSM 07.01, the DTE/DCE interface is normally associated with the terminal adaptation function (TAF), if such a function is available. When no data connection is in progress, and the terminal equipment wishes to enter SMS/CBS mode, the command ‘AT+CESP’ shall be issued by the TE through the DTE/DCE interface requesting that the Block mode protocol described in this specification is to be used. The syntax of this command is further described in subclause 3.2.4 later. The syntax for these commands is derived from V.25ter, i.e. the command is encoded as an IA5 character string together with delimiters as described in V.25ter.

Upon receipt of this command, the mobile termination shall respond as follows:

If the mobile termination supports SMS/CBS block mode commands, responses and indications as described in this technical specification, it shall respond with ‘OK’ (or 0) and enter the SMS/CBS mode.

If the mobile termination does not support SMS/CBS block mode commands, responses and indications as described in this technical specification, it shall respond with ‘ERROR’ (or 4) and remain in the current mode..

Terminal software shall wait a short time (e.g. 5 seconds) for the ‘OK’ (0) or ‘ERROR’ (4) response. If neither response is received before the timeout then the terminal software shall assume that the block mode has been entered. The terminal software may then submit its first block mode command. If no response is received to this command then the terminal software shall proceed as described below in subclause 2.2 (i.e. repeat the command 3 times and then exit the block mode).

If the SMS/CBS block mode command is accepted by the mobile termination, then all further commands, responses and indications shall be as defined in clause 2 of this technical specification. These SMS/CBS mode commands, responses and indications use 8-bit encoded data and not IA5 characters.

2.1.2 Returning from SMS/CBS Block Mode To Default Mode

When the terminal equipment wishes to return to default mode from SMS/CBS mode, it shall issue the command ‘END SMS MODE’, described in subclause 2.4.1.11. The mobile termination shall respond with ‘OK’ (or 0) to indicate that the DTE/DCE interface has returned to default mode. The TE shall change back to default mode whether or not such a response is received.

The TE may also indicate that it has exit from the SMS/CBS mode through the use of CT 108/2 (see subclause 1.1)

If an incoming data call arrives while the DTE/DCE interface is set to SMS/CBS mode, then the mobile termination may autonomously issue the ‘END SMS MODE’ indication (subclause 2.4.2.11) and revert to default mode in order to connect the data call through the TAF.

The MT may exit from SMS/CBS mode autonomously if the power to the MT is switched off and then on again. In addition, the MT manufacturer may provide MMI to change the mode back to the default mode. In the latter case, the MT shall issue the ‘END SMS MODE’ indication (subclause 2.4.2.11) and exit the SMS/CBS mode immediately.

The MT may also indicate that it has exit from the SMS/CBS mode through the use of CT 107 and
CT 109 (see subclause 1.1).

A BREAK condition in either direction at the DTE/DCE interface shall cause the TE and the MT to exit from the SMS/CBS block mode and return to the default mode.

In the event where the TE or the MT find themselves unable to recover from a protocol error then either entity may exit the SMS/CBS mode using any of the mechanisms described above. Confirmation of default mode operation will be achieved through the use of AT commands and responses.

2.2 Protocol description

The communication path between the MT and the TE across the DTE/DCE interface should be quite reliable if it uses a short wire link. However, to ensure that the low error rate does not cause malfunction, the following error protection scheme is provided.

Each message sent from the MT to the TE or vice-versa consists of a data block (DATA) and block check sum (BCS, see figure 2.2.1). In the following description the notation DLE, STX, NUL and ETX refer to control characters having the values 10 02 00 and 03 hexadecimal respectively.

<—————–DATA—————–> <- BCS ->

DLE

STX

Message content

DLE

ETX

BCS

BCS

10H

02H

10H

03H

MSB

LSB

Figure 2.2.1/GSM 07.05: Format of DTE/DCE interface messages

The data block consists of a start transmission sequence, set to 00010000 00000010 (10 02 hex), the message content as defined below and an end transmission sequence, set to 00010000 00000011 (10 03 hex). The least significant bit of each octet is always transmitted first.

The block check sum is calculated at the transmitter by adding all of the octets in the message content modulo 65536. Each bit of the 16-bit result is then inverted, and 1 is added to the answer.

During transmission of the message content and the BCS octets, any occurrence of the value 10 hex (DLE) shall result in an additional ‘stuffing’ octet of value 00 hex (NUL) being transmitted immediately following the octet containing 10 hex. This is to ensure that the start and end markers are unambiguous. The receiver shall remove stuffing octets by discarding any octet of value 00 hex (NUL) which immediately follows an octet of value 10 hex (DLE).

After removal of any stuffing octets, the receiver can check the BCS by adding all of the octets in the message content and the 16-bit BCS modulo 65536. The correct result is 0000 hex. If any message is received with an incorrect BCS, then the message is discarded. No response is sent over the DTE/DCE interface, but an indication may be provided to higher layers within the receiving entity.

The transmitter shall only send DLE when it is followed by STX, NUL or ETX. Therefore, if the receiver sees a DLE followed by anything else then the receiver shall assume that some data has been lost, and shall start to search for the start marker. An unexpected end marker at the receiver shall also result in a search for a start marker. A start marker shall always be treated as the start of a new block, regardless of which state the receiver is in.

Examples of state diagrams for a block receiver to implement this procedure are given in Annex B, together with an example of coding and decoding a message.

Only one Command/Response transaction shall be permitted at any one time from any sending or receiving entity. It shall however be possible for a Command/Response transaction from one entity to be initiated even if there is a Command/Response transaction in progress from the other entity.

If an immediate response is expected to a message sent over the DTE/DCE interface, then the sending entity shall wait 10 seconds. If no response is received within this time, the sending entity shall repeat the message. The message shall be repeated a maximum of 3 times, after which the sending entity shall exit from the SMS/CBS mode and provide an error indication to the user.

If a message cannot be understood by the receiving entity even though it has a correct BCS, then it shall return an UNABLE TO PROCESS message with cause value ‘Command not understood’. The receipt of an UNABLE TO PROCESS message should not in itself initiate re-transmission although re-transmission may take place due to the timeout mechanism described earlier since an UNABLE TO PROCESS is deemed to be an invalid response. The ‘Cause’ may however be referred to a higher layer. An UNABLE TO PROCESS shall not be sent as the result of an incorrect BCS.

2.3 Requesting messages already held in the Mobile Termination

The TE may request the MT to provide SMS or CBS messages already stored. The TE will either request all messages, or request a list of messages and subsequently ask for specific messages.

At the start of the SMS/CBS mode session, the MT shall number all messages contiguously, starting with message number 1. These "Short Message References" are only valid for a single SMS/CBS MODE session and should not be confused with the GSM 03.40 TP-Message-Reference. Each message retains its Short Message Reference for the duration of the SMS/CBS mode session. New messages will normally be given the lowest previously-unused Short Message Reference. However, if all Short Message References have been used then the MT may reallocate Short Message References previously allocated to now-deleted messages.

Short Message Reference 0 signifies that there are no messages in the MT. The value of 0 is used under the following conditions:

– When an INSERT SMS command is used to transfer an SM over the air interface and not store it in the MT then the MT will return a Short Message Reference of 0 in the REQUEST CONFIRMED response and the ensuing INSERT SMS COMPLETE / INSERT SMS FAILURE indications.

– For Class 0 SM’s which are not stored in the MT

– For TE specific SM’s which are not stored in the MT

If Message number 0 is requested by the TE, the MT will always return an error cause, but will also include the highest valid Short Message Reference (see subclause 2.3.2.1 below).

2.3.1 Requesting List Of Messages

The TE may request the MT to provide a list of SMS and CBS messages currently stored in the mobile termination. This is achieved by the LIST REQUEST command (subclause 2.4.1.1). The MT divides the messages stored into groups of 5 (called pages) and transfers the first 5 in a MESSAGE LIST response (subclause 2.4.2.1) containing message references allocated by the MT, plus the relevant header information described in GSM 03.40/04.11 and GSM 03.41/04.12.

If there are no messages stored in the MT, then the MESSAGE LIST response shall be empty.

The TE may then request further groups of up to 5 messages by repeating the LIST REQUEST command for pages 2,3, and so on. The MT will indicate that there are no more pages by responding with an empty MESSAGE LIST response.

2.3.2 Requesting Transfer Of Messages

The TE may request the transfer of one or more messages by means of the commands described below. The MT does not delete messages which have been transferred. Messages can only be deleted by the DELETE MESSAGE command (subclause 2.4.1.9).

2.3.2.1 Requesting Transfer Of A Specific Message

The TE may request the MT to transfer a specific message by sending the GET MESSAGE command (subclause 2.4.1.2), including the appropriate message reference. The MT will provide the full message including header in a MESSAGE response (subclause 2.4.2.2). If the message reference is unallocated, then the GET MESSAGE FAILURE response is returned with cause ‘No such message’ and the highest valid Message Reference (subclause 2.4.2.3).

2.3.2.2 Requesting Transfer Of All Messages

The TE may request the MT to transfer all messages by sending the GET FIRST MESSAGE command (subclause 2.4.1.3), followed by the appropriate number of GET NEXT MESSAGE commands (subclause 2.4.1.4).

The MT shall be able to transfer all messages one-by-one, starting with the ‘first’ and continuing with the ‘next’. The precise ordering of the messages is left to the MT implementation.

If the MT exits from SMS/CBS mode for any reason, then this information need not be retained.

On receipt of the GET FIRST MESSAGE command, the MT shall set a pointer to the first message, and transfer this message using the MESSAGE response as described in subclause 2.3.2.1.

On receipt of the GET NEXT MESSAGE command, the MT shall move the pointer to the first available message after the last message transferred (using either GET FIRST MESSAGE, GET MESSAGE or GET NEXT MESSAGE), and transfer this message using the MESSAGE response as described in subclause 2.3.2.1.

If the MT receives a GET NEXT MESSAGE command when all messages have been transferred to the TE, or there are no messages stored in the MT, then the GET MESSAGE FAILURE response shall be provided with the cause ‘No such message’ (see subclause 2.4.2.3).

If the TE receives an out of sequence message then it shall attempt to transfer the missing message using the GET MESSAGE command before continuing with GET NEXT MESSAGE. If this attempt fails with the cause ‘no such message’, it means that the message has been deleted, or it has been lost due to a failure at the MT.

The MT includes a LAST SHORT MESSAGE REFERENCE in the GET MESSAGE FAILURE response. This is so that the TE can detect whether or not the last short message was received in error.

If the MT receives a GET NEXT MESSAGE command prior to receiving a GET FIRST MESSAGE or GET MESSAGE command, then it shall continue as if the command had been GET FIRST MESSAGE (i.e. provide the ‘first’ message and continue with the ‘next’ on receipt of the subsequent GET NEXT MESSAGE command).

2.3.3 Requesting Diversion Of Incoming Messages

The TE may request the MT to transfer SMS or CBS messages directly from the air interface to the DTE/DCE interface, by the following procedures. If messages are diverted then they are not stored in the MT. If messages are diverted and there is no communication path to the TE (e.g. because it has been disconnected), the diversion shall be cancelled.

2.3.3.1 Requesting SMS Messages

The TE may request an indication of arrival of incoming SMS messages, or the direct transfer of incoming SMS messages.

The TE requests new SMS messages by the TRANSFER INC SMS command (subclause 2.4.1.5). This command will be sent with parameters indicating whether all incoming SMS messages are to be transferred, or only those indicated as being for the TE.

The MT shall confirm receipt of this command with a REQUEST CONFIRMED message provided there is memory available to store SM’s in the ME or the SIM. If there is no memory available, the MT shall respond with ‘unable to process’ with a cause value No memory.

The MT shall transfer incoming messages by the INC MESSAGE indication (subclause 2.4.2.4).

For an INC MESSAGE which contains a Short Message (SMS) info element id, the TE shall acknowledge receipt of the INC MESSAGE with an ACKNOWLEDGE MESSAGE (subclause 2.4.1.12). The MT should not send another INC MESSAGE which contains a Short Message (SMS) info element id to the TE whilst it is waiting for an ACKNOWLEDGE MESSAGE.

In the event of the MT not receiving an ACKNOWLEDGE MESSAGE within a time specified by the MT manufacturer the MT shall exit the SMS mode automatically after ‘n’ attempts to send the INC MESSAGE (where n is a number specified by the MT manufacturer). The MT should attempt to store the unacknowledged SM or Status Report (contained in the INC MESSAGE) in the MT or on the SIM as appropriate.

The ACKNOWLEDGE MESSAGE sent from the TE to the MT must not delay the MT sending the RP-ACK defined in GSM  03.40 (to the SC) for longer than the RP-ACK timeout specified in GSM  04.08.

The TE requests the cessation of incoming message transfer by the same command, indicating no incoming messages. The transfer of messages will automatically cease on exit of the SMS/CBS mode. Transfer shall not recommence until a new request is issued by the TE.

2.3.3.2 Requesting CBS Messages

The TE may request the transfer of all cell broadcast messages directly from the air interface to the DTE/DCE interface. This is achieved by the use of the TRANSFER INC CBS message (subclause 2.4.1.7).

The MT shall confirm receipt of this command with a REQUEST CONFIRMED message.

After receipt of this command, the MT shall transfer all CBS pages as they arrive on the air interface, using the INC MESSAGE indication (subclause 2.4.2.4).

While the CBS pages are being transferred, any other indication or response required to be sent to the TE will take precedence over the CBS pages. However, the MT shall not interrupt the transfer of a page to send other information within the SMS/CBS mode (ie. the MT shall wait until a page boundary).

The transfer of messages will automatically cease on exit of the SMS/CBS mode. Transfer shall not recommence until a new request is issued by the TE.

2.3.3.3 Requesting indication of message arrival

If the TE requires an indication of incoming message arrival, the INDICATE INC SMS command (subclause 2.4.1.6) shall be used.

The MT shall confirm receipt of this command with a REQUEST CONFIRMED message.

After receipt of this command, the MT shall indicate all incoming messages in the specified categories (unless they are directly transferred) with the MESSAGE ARRIVED indication (subclause 2.4.2.5). This indication shall be of the same format as the MESSAGE LIST response described in subclause 2.3.1.

The TE shall acknowledge receipt of the MESSAGE ARRIVED with an ACKNOWLEDGE MESSAGE. (subclause 2.4.1.12). The MT should not send another MESSAGE ARRIVED to the TE whilst it is waiting for an ACKNOWLEDGE MESSAGE.

In the event of the MT not receiving an ACKNOWLEDGE MESSAGE within a time specified by the MT manufacturer the MT shall exit the SMS mode automatically after ‘n’ attempts to send the MESSAGE ARRIVED (where n is a number specified by the MT manufacturer). The MT should attempt to store the unacknowledged SM or Status Report in the MT or on the SIM as appropriate.

The ACKNOWLEDGE MESSAGE sent from the TE to the MT must not delay the MT sending the RP-ACK defined in GSM 03.40 (to the SC) for longer than the RP-ACK timeout specified in the GSM 04.08.

The TE requests the cessation of incoming message indication by the INDICATE INC SMS command, with the ‘no incoming messages’ parameter.

2.3.4 Requesting Transfer Into Mobile Termination

The TE may request transfer of SMS messages into the mobile termination. Cell broadcast messages cannot be transferred in this direction.

The TE shall use the INSERT SMS command (subclause 2.4.1.8) to transfer the message. This command shall indicate whether the message is to be stored in the MT, sent over the air interface or both. The command shall include the full SMS message and header as described in GSM 03.40, except for the message reference and message type indication (which are allocated by the MT).

Only one INSERT SMS command may be outstanding at any given instant. An INSERT SMS is deemed complete when an INSERT SMS COMPLETE or an INSERT SMS FAILURE indication has been received irrespective of whether an intermediate REQUEST CONFIRMED has been received.

Upon receipt of an INSERT SMS command, the MT shall act in the following way:

If the TE requested the MT to store the message, the MT shall attempt to store the message. If the attempt is successful, the MT shall return an INSERT SMS COMPLETE indication (subclause 2.4.2.6), including the message reference allocated by the MT. If the attempt fails (eg. due to lack of memory), the MT shall return an INSERT SMS FAILURE indication (subclause 2.4.2.7), providing a cause for the failure.

If the TE requested the MT to send the message, the MT shall respond immediately with a REQUEST CONFIRMED message, and attempt to send the message. If the send attempt subsequently succeeds, the MT shall send an INSERT SMS COMPLETE indication, including the message references allocated by the MT. If the send attempt subsequently fails, the MT shall return an INSERT SMS FAILURE indication, providing a cause for the failure.

If the TE requested the MT to store and send the message, the MT shall first attempt to store the message. If no storage is available, the MT shall return an INSERT SMS FAILURE indication (subclause 2.4.2.7) and shall not attempt to send the message. If storage is available, the MT shall store the message and then respond with a REQUEST CONFIRMED message. If the send attempt is successful, the MT shall return an INSERT SMS COMPLETE indication (subclause 2.4.2.6), including the message references allocated by the MT. If the transmission of the message fails, then the MT shall return an INSERT SMS FAILURE indication (subclause 2.4.2.7). This will show that the send attempt failed and provide a cause. After that the MT shall delete the stored message.

2.3.5 Requesting Deletion Of Messages

The TE may request deletion of SMS or CBS messages from the store in the MT. This is achieved by the DELETE MESSAGE command (subclause 2.4.1.9). The command will include a message reference, as defined by the MT and provided in the message list.

Upon receipt of this command, the MT shall attempt to delete the message. If successful, the MT shall return a DELETE MESSAGE COMPLETE indication (subclause 2.4.2.8). If not successful, the MT shall return a DELETE MESSAGE FAILURE indication (subclause 2.4.2.9).

On successful deletion of an SM or CBS message the Page Index (see 2.5.2.10) and the Index Count (see 2.5.2.8) shall be re-assigned so that their values are contiguous (i.e. there are no gaps in either parameter). The original short message Reference values remain unchanged.

2.4 Message functional definitions and contents

This subclause provides an overview of the message structure to be used over the DTE/DCE interface in SMS/CBS block mode. Each message definition includes a brief description of the use of the message, and a table showing all the information elements which may be included in the message. If an entity receives a message containing more information elements than expected then the receiving entity shall ignore the additional information elements. For each information element the following data are provided:

Reference – this indicates where the detailed description of each element can be found.

Presence:

M

Mandatory

must always be present

receiver: If not present, consider message erroneous

C

Conditional

presence depending on e.g.

a) value of other element

b) presence of optional element

receiver: If not present when condition met, consider message

erroneous

O

Optional

presence is a choice of the sender

receiver: present or not, accept message

Format:

T

Type only, fixed length, only IEI

V

Value only, fixed length, no IEI included

TV

Type and value, fixed length, IEI included

LV

Length and value, variable length, no IEI included and Length indicator included

TLV

Type, Length and Value, variable length, IEI and length indicator included

Length – this indicates the length of the information element in octets.

2.4.1 Commands Issued By The Terminal Equipment

Table 2.4.1/GSM 07.05 summarises the commands which may be issued by the TE.

Table 2.4.1/GSM 07.05: Commands which may be issued by the TE

Reference

LIST REQUEST

2.4.1.1

GET MESSAGE

2.4.1.2

GET FIRST MESSAGE

2.4.1.3

GET NEXT MESSAGE

2.4.1.4

TRANSFER INC SMS

2.4.1.5

INDICATE INC SMS

2.4.1.6

TRANSFER INC CBS

2.4.1.7

INSERT SMS

2.4.1.8

DELETE MESSAGE

2.4.1.9

UNABLE TO PROCESS

2.4.1.10

END SMS MODE

2.4.1.11

ACKNOWLEDGE MESSAGE

2.4.1.12

2.4.1.1 List Request

This message is sent by the TE to the MT to request a list of messages stored in the MT.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Page Index

2.5.2.10

M

V

1

2.4.1.2 Get Message

This message is sent by the TE to the MT to request transfer of a specific SMS or CBS message stored in the MT.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Short Message Reference

2.5.2.1

M

V

1

2.4.1.3 Get First Message

This message is sent by the TE to the MT to request transfer of the first available SMS or CBS message stored in the MT.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

2.4.1.4 Get Next Message

This message is sent by the TE to the MT to request transfer of the next available SMS or CBS message stored in the MT.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

2.4.1.5 Transfer Inc SMS

This message is sent by the TE to the MT to request the direct transfer of incoming messages from the air interface to the TE.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

SMS Transfer Type

2.5.2.2

M

V

1

2.4.1.6 Indicate Inc SMS

This message is sent by the TE to the MT to request that the MT indicates when an incoming message arrives.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Indication Type

2.5.2.3

M

V

1

2.4.1.7 Transfer Inc CBS

This message is sent by the TE to the MT to request transfer of all cell broadcast messages directly from the air interface to the DTE/DCE interface.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

CBS Transfer Type

2.5.2.9

M

V

1

2.4.1.8 Insert SMS

This message is sent by the TE to the MT to request the transfer of an SMS TPU to the MT memory or across the air interface. The TPDU is formatted in exactly the same way as described in TS 03.40. Where the TPDU includes a TP-Message-Reference which is to be incremented by the MT for every outgoing message, the TP-Message-Reference provided by the TE will be overwritten by the MT before transmission of the message. The value provided by the TE is discarded by the MT and has no significance.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Insert Type

2.5.2.4

M

V

1

RP-Destination-Address

GSM 04.11

M

LV

1-12 a)

SMS-TPDU

GSM 03.40

M

V

max 164

a) If no RP-Destination-Address is to be transferred then the length is set to 0. In this case, the MT inserts the default SC address.

2.4.1.9 Delete message

This message is sent from the TE to the MT to request deletion of a specific SMS or CBS message held in the MT.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Short Message Reference

2.5.2.1

M

V

1

2.4.1.10 Unable to process

This response is sent from the TE to the MT to indicate that the MT’s message could not be processed.

Information element

Preference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Cause

2.5.2.7

M

V

1

2.4.1.11 End SMS Mode

This message is sent from the TE to the MT to terminate the SMS/CBS mode of the DTE/DCE interface.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

2.4.1.12 Acknowledge Message

This message is sent from the TE to the MT to acknowledge receipt of a INC MESSAGE or MESSAGE ARRIVED which contains a Short Message (SMS) info element id, (e.g. a Short Message or a Status Report but not a CBS message.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

SM-Deliver-Ack

2.5.2.14

O

TLV

2 to 160

2.4.2 Responses/Indications Issued By The MT

Table 2.4.2/GSM 07.05 summarises the responses/indications which may be issued by the MT.

Table 2.4.2/GSM 07.05: Responses/Indications which may be issued by the MT

Reference

MESSAGE LIST

2.4.2.1

MESSAGE

2.4.2.2

GET MESSAGE FAILURE

2.4.2.3

INC MESSAGE

2.4.2.4

MESSAGE ARRIVED

2.4.2.5

INSERT SMS COMPLETE

2.4.2.6

INSERT SMS FAILURE

2.4.2.7

DELETE MESSAGE COMPLETE

2.4.2.8

DELETE MESSAGE FAILURE

2.4.2.9

UNABLE TO PROCESS

2.4.2.10

END SMS MODE

2.4.2.11

REQUEST CONFIRMED

2.4.2.12

2.4.2.1 Message List

This response is sent from the MT to the TE on receipt of a LIST REQUEST from the TE.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Page Index

2.5.2.10

M

V

1

Index Count

2.5.2.8

M

V

1

Short Message Index (1)

2.5.2.5

O

TLV

8-48

Short Message Index (2)

2.5.2.5

O

TLV

8-48

:

:

:

:

:

Short Message Index (n)

2.5.2.5

O

TLV

8-48

The number of Short Message Indices included in the message may be 0, 1, 2, 3, 4 or 5.

2.4.2.2 Message

This response is sent from the MT to the TE when a short message has been requested.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Short Message Data

2.5.2.6

M

TLV

28-181

2.4.2.3 Get Message Failure

This response is sent from the MT to the TE when a request for a short message cannot be fulfilled.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Last Short Message

2.5.2.11

M

V

1

Cause

2.5.2.7

M

V

1

2.4.2.4 Inc Message

This indication is sent from the MT to the TE after the MT has been requested to transfer messages of certain categories immediately upon receipt.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Short Message Data

2.5.2.6

M

TLV

28-181

2.4.2.5 Message Arrived

This indication is sent from the MT to the TE after the MT has been requested to provide an indication of the receipt of certain categories of incoming message.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Short Message Index

2.5.2.5

M

TLV

8-48

2.4.2.6 Insert SMS Complete

This response is sent by the MT to the TE to indicate that the TE’s request to insert a message has been completed.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Short Message Reference

2.5.2.1

M

V

1

TP-Message Reference

GSM 03.40

C a)

V

1

SM-Submit-Ack

2.5.2.15

O

TLV

2 to 160

a) The TP-Message Reference is only included if the message had been requested to be transferred over the air interface.

2.4.2.7 Insert SMS Failure

This response is sent from the MT to the TE to indicate that the attempt to insert an SMS message failed.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Cause

2.5.2.7

M

V

1-2

TP-Failure Cause

2.5.2.13

O

TLV

4

Short Message Reference

2.5.2.1

O

TV

2

2.4.2.8 Delete Message Complete

This response is sent from the MT to the TE to indicate that the request to delete a message from the MT store has been completed.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Short Message Reference

2.5.2.1

M

V

1

2.4.2.9 Delete Message Failure

This response is sent from the MT to the TE to indicate that the request to delete a message from the MT store failed.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Short Message Reference

2.5.2.1

M

V

1

Cause

2.5.2.7

M

V

1

2.4.2.10 Unable To Process

This response is sent from the MT to the TE to indicate that the TE’s request could not be processed.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Cause

2.5.2.7

M

V

1

2.4.2.11 End SMS Mode

This indication is sent from the MT to the TE when the MT autonomously exits from SMS/CBS mode.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Cause

2.5.2.7

M

V

1

2.4.2.12 Request Confirmed

This indication is sent from the MT to the TE to indicate that the MT has received the request from the TE and will perform the requested function.

Information element

Reference

Presence

Format

Length

Message Type

2.5.1

M

V

1

Confirm Type

2.5.2.12

M

V

1

Short Message Reference

2.5.2.1

O

TV

2

2.5 General message format and information elements coding

This subclause describes the content of messages for the SMS/CBS mode of the DTE/DCE interface. Within the figures in this subclause, the bit designated "bit 1" is transmitted first, followed by bits 2,3,4 etc. Similarly, the octet shown at the top of each figure is sent first.

2.5.1 Message Type

The purpose of the message type is to identify the function of the message being sent. The message type is coded as shown in figure 2.5.1/GSM 07.05 and table 2.5.1/GSM 07.05.

Bit 8 is reserved for possible future use as an extension bit.

8

7

6

5

4

3

2

1

0

Message Type

octet 1

Figure 2.5.1/GSM 07.05: Message Type

Table 2.5.1/GSM 07.05: Message Types

8

7

6

5

4

3

2

1

0

0

0

Commands/ Responses issued by TE

0

0

0

0

0

0

0

0

LIST REQUEST

0

0

0

0

0

0

0

1

GET MESSAGE

0

0

0

0

0

0

1

0

GET FIRST MESSAGE

0

0

0

0

0

0

1

1

GET NEXT MESSAGE

0

0

0

0

0

1

0

0

TRANSFER INC SMS

0

0

0

0

0

1

0

1

INDICATE INC SMS

0

0

0

0

0

1

1

0

TRANSFER INC CBS

0

0

0

0

0

1

1

1

INSERT SMS

0

0

0

0

1

0

0

0

DELETE MESSAGE

0

0

0

0

1

0

0

1

UNABLE TO PROCESS

0

0

0

1

1

1

1

0

END SMS MODE

0

0

0

1

1

1

1

1

ACKNOWLEDGE MESSAGE

0

0

1

Responses/Indications issued by MT

0

0

1

0

0

0

0

0

MESSAGE LIST

0

0

1

0

0

0

0

1

MESSAGE

0

0

1

0

0

0

1

0

GET MESSAGE FAILURE

0

0

1

0

0

0

1

1

INC MESSAGE

0

0

1

0

0

1

0

0

MESSAGE ARRIVED

0

0

1

0

0

1

0

1

INSERT SMS COMPLETE

0

0

1

0

0

1

1

0

INSERT SMS FAILURE

0

0

1

0

0

1

1

1

DELETE MESSAGE COMPLETE

0

0

1

0

1

0

0

0

DELETE MESSAGE FAILURE

0

0

1

0

1

0

0

1

UNABLE TO PROCESS

0

0

1

0

1

0

1

0

REQUEST CONFIRMED

0

0

1

1

1

1

1

1

END SMS MODE

All other values are reserved. If a reserved Message Type is received then the receiving entity shall return “Unable to Process” with Cause “Command not understood”.

2.5.2 Other Information Elements

Other information elements follow the general coding principles specified in GSM 04.08, and are described in the following subclauses.

2.5.2.1 Short Message Reference

The Short Message Reference uniquely identifies a short message stored in the MT. It is an 8 bit number and is allocated by the MT.

The Short Message Reference information element is coded as shown in figure 2.5.2/GSM 07.05 and table 2.5.2/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

0

octet 1

Short Message Reference info element id

Short Message Reference value

octet 2

Figure 2.5.2/GSM 07.05: Short Message Reference information element

Table 2.5.2/GSM 07.05: Short Message Reference information element

Short Message Reference value (octet 2). In the Short Message Reference value field bit 8 of octet 2 is the most significant bit and bit 1 of octet 2 is the least significant bit. Short Message Reference values are allocated by the MT.

2.5.2.2 SMS Transfer Type

The SMS Transfer Type indicates to the MT which SMS messages are required to be transferred to the TE.

The SMS Transfer Type information element is coded as shown in figure 2.5.3/GSM 07.05 and table 2.5.3/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

0

0

0

1

octet 1

SMS Transfer Type info element ident

0

0

0

0

0

SMS Txfr

octet 2

Reserved

Type value

Figure 2.5.3/GSM 07.05: SMS Transfer Type information element

Table 2.5.3/GSM 07.05: SMS Transfer Type information element

SMS Txfr Type value (octet 2). The SMS txfr type is coded as follows: bit 2 bit 1 0 0 Transfer no SMS messages 0 1 Transfer SMS messages marked as TE-specific 1 0 Reserved
1 1 Transfer all SMS messages Bit 3 shows whether to transfer SMS-STATUS-REPORTS Bit 3 0 Do not transfer SMS-STATUS-REPORTS 1 Transfer SMS-STATUS-REPORTS

A receiving entity shall ignore the setting of bits 8-4. If bit 2 is set to 1 and bit 1 is set to 0 then the receiving entity shall return “Unable to Process” with cause “Command Not Understood”

2.5.2.3 Indication Type

The Indication Type tells the MT when to notify the TE that an incoming message has been received.

The Indication Type information element is coded as shown in figure 2.5.4/GSM 07.05 and table 2.5.4/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

0

0

1

0

octet 1

Indication Type info element identifier

0

0

0

0

Indication Type

octet 2

Reserved

value

Figure 2.5.4/GSM 07.05: Indication Type information element

Table 2.5.4/GSM 07.05: Indication Type information element

Indication Type value (octet 2). The indication type is coded as follows: bit 3 bit 2 bit 1 0 0 0 Indicate no messages 0 0 1 Reserved
0 1 0 Indicate all SMS messages 0 1 1 Indicate SMS messages marked as TE-specific 1 0 0 Indicate all CBS messages 1 0 1 Indicate CBS messages marked as TE-specific 1 1 0 Indicate all CBS and SMS messages
1 1 1 Indicate SMS and CBS messages marked
as TE-specific Bit 4 shows whether or not to indicate SMS reports: bit 4 0 Do not indicate SMS reports
1 Indicate SMS reports A receiving entity shall ignore the setting of bits 8-5. If bits 3 and 2 are set to 0 and bit 1 is set to 1 then the receiving entity shall return “Unable to Process” with cause “Command Not Understood”.

2.5.2.4 Insert Type

The Insert Type tells the MT what to do with the short message arriving from the TE.

The Insert Type information element is coded as shown in figure 2.5.5/GSM 07.05 and table 2.5.5/GSM 07.05

8

7

6

5

4

3

2

1

0

0

0

0

0

0

1

1

octet 1

Insert Type info element identifier

0

0

0

0

0

0

Insert

octet 2

Reserved

Type value

Figure 2.5.5/GSM 07.05: Insert Type information element

Table 2.5.5/GSM 07.05: Insert Type information element

Insert Type value (octet 2).

The insert type is coded as follows:

bit 2 bit 1
0 0 Reserved
0 1 Store the short message in the MT
1 0 Send the short message over the air
1 1 Store the short message in the MT and send it over the air

A receiving entity shall ignore the setting of bits 8-3. If bits 2 and 1 are set to 0 then the receiving entity shall return “Unable to Process” with cause “Command Not Understood”

2.5.2.5 Short Message Index

The Short Message Index provides information about each individual short message currently stored in the MT. Two types of Short Message index are provided; one for SMS and one for CBS.

The Short Message Index (SMS) information element is coded as shown in figure 2.5.6/GSM 07.05 and table 2.5.6/GSM 07.05. A Short Message Index may be an SMS-SUBMIT, an SMS-DELIVER or an SMS-STATUS-REPORT.

The Short Message Index (CBS) information element is coded as shown in figure 2.5.7/GSM 07.05 and table 2.5.7/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

0

1

0

0

octet 1

Short Message Index (SMS) info element id

Length of Short Message Index

octet 2

Short Message Reference value

octet 3

Short Message Status

octet 4

Service Centre Address

octets

5-n

Short Message Header (SMS)

octets

n+1 – n+31

Figure 2.5.6/GSM 07.05: Short Message Index (SMS) information element

n can take a value between 5 and 18 (inclusive)

Table 2.5.6/GSM 07.05: Short Message Index (SMS) information element

Short Message Reference value (octet 3). The Short Message Reference value is coded as specified in table 2.5.2/GSM 07.05. Short Message Status (octet 4). The Short Message Status is coded as follows: 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 Not read/not sent 0 0 0 0 0 0 0 1 Read/Sent
0 0 0 0 0 1 0 0 Not Read 0 0 0 0 0 1 0 1 Read
0 0 0 0 0 1 1 0 Not Sent 0 0 0 0 0 1 1 1 Sent

All other values are reserved. The receiving entity shall ignore the setting of bits 8-4. In addition, if bit 3 is set to 0 then a receiving entity shall ignore the setting of bit 2. Where bit 3 is set to 0, if the message is mobile originated then bit 1 indicates whether the message has been sent to the network. If the message is mobile terminated then bit 1 indicates whether the message has been read. Service Centre Address (Octets 5-n). The Service Centre Address is coded as the RP-Origination or RP-Destination address specified in GSM 04.11. If the short message is mobile originated, the address will be the RP-Destination address. If the short message is mobile terminated, the address will be the RP-Origination address. The address is of variable length, 1-12 octets. Short Message Header (SMS) (Octets n+1 – n+31). The Short Message Header (SMS) is coded as a TPDU as described in GSM 03.40. In the case of SMS-DELIVER or SMS-SUBMIT, the TP-User-Data is not included, but the TP-User-Data-Length is included. The Short Message Header is of variable length, 6-31 octets.

8

7

6

5

4

3

2

1

0

0

0

0

0

1

0

1

octet 1

Short Message Index (CBS) info element id

Short Message Reference value

octet 2

Short Message Header (CBS)

octets

3-8

Figure 2.5.7/GSM 07.05: Short Message Index (CBS) information element

Table 2.5.7/GSM 07.05: Short Message Index (CBS) information element

Short Message Reference value (octet 2). The Short Message Reference value is coded as specified in table 2.5.2/GSM 07.05. Short Message Header (CBS) (Octets 3-8). The Short Message Header (CBS) is coded as described in GSM 03.41, including SEQUENCE NUMBER, MESSAGE IDENTIFIER, ALPHABET IDENTIFIER and PAGE PARAMETER, but excluding the characters of the message.

2.5.2.6 Short Message Data

The Short Message Data information element is a copy of a short message currently stored in the MT. Two types of Short Message Data information element are provided; one for SMS and one for CBS.

The Short Message Data (SMS) information element is coded as shown in figure 2.5.8/GSM 07.05 and table 2.5.8/GSM 07.05. Short Message Data may be an SMS-SUBMIT, an SMS-DELIVER or an SMS-STATUS-REPORT.

The Short Message Data (CBS) information element is coded as shown in figure 2.5.9/GSM 07.05 and table 2.5.9/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

0

1

1

0

octet 1

Short Message Data (SMS) info element id

Length of Short Message Data

octet 2

Short Message Reference value

octet 3

Short Message Status

octet 4

Service Centre Address

octets

5-n

Short Message (SMS)

octets

n+1-n+164

Figure 2.5.8/GSM 07.05: Short Message Data (SMS) information element

n can take a value between 5 and 18 (inclusive)

Table 2.5.8/GSM 07.05: Short Message (SMS) information element

Short Message Reference value (octet 3). The Short Message Reference value is coded as specified in table 2.5.2/GSM 07.05. Short Message Status (octet 4). The Short Message Status is coded as follows: 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 Not read/not sent 0 0 0 0 0 0 0 1 Read/Sent 0 0 0 0 0 1 0 0 Not Read 0 0 0 0 0 1 0 1 Read
0 0 0 0 0 1 1 0 Not Sent 0 0 0 0 0 1 1 1 Sent

All other values are reserved. The receiving entity shall ignore the setting of bits 8-4. In addition, if bit 3 is set to 0 then a receiving entity shall ignore the setting of bit 2. Where bit 3 is set to 0, if the message is mobile originated then bit 1 indicates whether the message has been sent to the network. If the message is mobile terminated then bit 1 indicates whether the message has been read. Service Centre Address (Octets 5-n). The Service Centre Address is coded as the RP-Origination-Address or RP-Destination Address specified in GSM 03.40. If the short message is mobile originated, the address will be the RP-Destination address. If the short message is mobile terminated, the address will be the RP-Origination Address. The address is of variable length, 1-12 octets. Short Message (SMS) (Octets n+1 – n+164). The Short Message (SMS) is coded as a TPDU as described in GSM 03.40. The Short Message is of variable length, 6-164 octets.

8

7

6

5

4

3

2

1

0

0

0

0

0

1

1

1

octet 1

Short Message Data (CBS) info element id

Short Message Reference value

octet 2

Short Message (CBS)

octets

3-90

Figure 2.5.9/GSM 07.05: Short Message Data (CBS) information element

Table 2.5.9/GSM 07.05: Short Message Data (CBS) information element

Short Message Reference value (octet 2). The Short Message Reference value is coded as specified in table 2.5.2/GSM 07.05. Short Message (CBS) (Octets 3-90). The Short Message (CBS) is coded as described in GSM 03.41, including SEQUENCE NUMBER, MESSAGE IDENTIFIER, ALPHABET IDENTIFIER, PAGE PARAMETER and CHARACTERS OF THE MESSAGE.

2.5.2.7 Cause

The Cause information element provides more detail as to why an error has occurred. The Cause information element is coded as shown in figure 2.5.10/GSM 07.05 and table 2.5.10/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

1

0

0

0

octet 1

Cause information element identifier

0

octet 2

ext

Cause value

04.11 RP-Cause value

octet 3

Figure 2.5.10/GSM 07.05: Cause information element

Table 2.5.10/GSM 07.05: Cause information element

Cause value (octet 2). The cause is coded as follows: 8 7 6 5 4 3 2 1
0 0 0 0 0 0 0 0 No such message – – no short message exists with the
provided shortmessage reference 0 0 0 0 0 0 0 1 No memory – – the short message cannot be stored
due to lack of memory 0 0 0 0 0 0 1 0 No air interface – – submission of the short message
cannot be attempted because the
mobile is out of coverage 0 0 0 0 0 0 1 1 Receiving entity busy – – the request was not fulfilled because
the Receiving entity is busy on
another task 0 0 0 0 0 1 0 0 Command not understood – – error in the coding of the command, or
command belongs to higher version of
protocol of protocol than that implemented 0 0 0 0 0 1 0 1 Incoming data call – – Incoming data call forces MT to exit from
SMS mode 0 0 0 0 0 1 1 0 User-invoked exit – – User has taken MT out of SMS by MMI
0 0 0 0 0 1 1 1 Other error
– – Any other error not covered here1 0 0 0 0 1 1 1 Message Transfer failed – – The SMS transfer to the SC failed and the
04.11 error cause is provided in octet 3 All other values are reserved. A receiving entity shall treat any reserved codings as “other error”.

04.11 RP-Cause value (octet 3) If this element is included then bit 8 of octet 2 is set to ‘1’. The error cause included in the RP-Cause over the air interface is directly mapped into this element. This element is only included if the MT attempts to send a short message to the network and that send attempt fails.

2.5.2.8 Index Count

The Index Count identifies the number of short message indices contained in a MESSAGE LIST response from the MT to the TE. It is an 8 bit number.

The Index Count information element is coded as shown in figure 2.5.11/GSM 07.05 and
table 2.5.11/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

1

0

0

1

octet 1

Index Count information element ident

Index Count value

octet 2

Figure 2.5.11/GSM 07.05: Index Count information element

Table 2.5.11/GSM 07.05: Index Count information element

Index Count value (octet 2). In the Index Count field bit 8 of octet 2 is the most significant bit and bit 1 of octet 2 is the least significant bit.

2.5.2.9 CBS Transfer Type

The CBS Transfer Type indicates to the MT which CBS messages are required to be transferred to the TE.

The CBS Transfer Type information element is coded as shown in figure 2.5.12/GSM 07.05 and
table 2.5.12/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

1

0

1

0

octet 1

CBS Transfer Type info element ident

0

0

0

0

0

0

CBS Txfr

octet 2

Reserved

Type value

Figure 2.5.12/GSM 07.05: CBS Transfer Type information element

Table 2.5.12/GSM 07.05: CBS Transfer Type information element

CBS Txfr Type value (octet 2). The CBS txfr type is coded as follows: bit 2 bit 1 0 0 Transfer no CBS messages 0 1 Transfer CBS messages marked as TE-specific 1 0 Reserved
1 1 Transfer all CBS messages

A receiving entity shall ignore the setting of bits 8-3. If bit 2 is set to 1 and bit 1 is set to 0 then the receiving entity shall return “Unable to Process” with cause “Command Not Understood”

2.5.2.10 Page Index

The Page Index indicates to the MT which Page of SMS Indices is required to be transferred. It also indicates to the TE which Page of SMS Indices is being transferred.

The Page Index information element is coded as shown in figure 2.5.13/GSM 07.05 and
table 2.5.13/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

1

0

1

1

octet 1

Page Index info element ident

0

0

Page Index value

octet 2

Reserved

Figure 2.5.13/GSM 07.05: Page Index information element

Table 2.5.13/GSM 07.05: Page Index information element

Page Index value (octet 2). In the Page Index field bit 6 of octet 2 is the most significant bit and bit 1 of octet 2 is the least significant bit. The Page Index can have a value from 1 to 51.

A receiving entity shall ignore the setting of bits 8 and 7. If the Page Index field has a value of 0 or a value greater than 51 then the receiving entity shall return “Unable to Process” with cause “Command Not Understood”

2.5.2.11 Last Short Message

The Last Short Message field indicates to the TE the highest value of Short Message Reference which points to a valid message stored in the MT. The value 0 signifies that there are no short messages stored in the MT.

The Last Short Message information element is coded as shown in figure 2.5.14/GSM 07.05 and table 2.5.14/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

1

1

0

0

octet 1

Last Short Message info element ident

Last Short Message value

octet 2

Figure 2.5.14/GSM 07.05: Last Short Message information element

Table 2.5.14/GSM 07.05: Last Short Message information element

Last Short Message value (octet 2). In the Last Short Message field bit 8 of octet 2 is the most significant bit and bit 1 of octet 2 is the least significant bit. The Last Short Message can have a value from 0 to 255.

2.5.2.12 Confirm Type

The Confirm Type field indicates the message to which the REQUEST CONFIRM is a response.

The Confirm Type information element is coded as shown in figure 2.5.15/GSM 07.05 and table 2.5.15/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

1

1

0

1

octet 1

Confirm Type info element ident

Confirm Type value

octet 2

Figure 2.5.15/GSM 07.05: Confirm Type information element

Table 2.5.15/GSM 07.05: Confirm Type information element

Confirm Type value (octet 2). The Confirm Type is coded as follows: 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 0 Reserved

0 0 0 0 0 0 0 1 Confirm request to transfer incoming
SMS messages 0 0 0 0 0 0 1 0 Confirm request to transfer incoming
CBS messages 0 0 0 0 0 0 1 1 Confirm request to indicate arrival of
messages in MT 0 0 0 0 0 1 0 0 Confirm request to attempt to send
short message (actual send is confirmed
later: see subclause 3.3) All other values are reserved. If any reserved value is received then the receiving entity shall return “Unable to Process” with cause value “Command Not Understood”.

2.5.2.13 TP-Failure Cause

This optional field is present if provided by the Relay Layer. The TP-Failure Cause is provided from the Service Centre and indicates to the TE the reason why the delivery of the message was unsuccessful. The TP-Failure cause information element is coded as shown in figure 2.5.16/GSM 07.05 and
table 2.5.16/GSM 07.05.

8

7

6

5

4

3

2

1

0

0

0

0

1

1

1

0

octet 1

Cause information element identifier

Length of Failure cause field

octet 2

Failure cause

octets 3-4

Figure 2.5.16/GSM 07.05: TP-Failure Cause information element

Table 2.5.16/GSM 07.05: TP-Failure Cause information element

Failure cause (octet 3-4) The failure cause contained in this field is directly mapped from the TP-Failure Cause (TP-FCS) field of the SMS-SUBMIT-REPORT message defined in GSM 03.40.

2.5.2.14 SM-Deliver-Ack

This optional field is sent from the TE to the MT to convey the information to be inserted into the SMS-DELIVER-REPORT RP-ACK TPDU sent by the MT to the SC as defined in GSM 03.40.

8

7

6

5

4

3

2

1

0

0

0

0

1

1

1

1

octet 1

SM-DELIVER-ACK information element identifier

Length of SMS-DELIVER-REPORT RP-ACK Field

octet 2

03.40 SMS-DELIVER-REPORT RP-ACK

octets 3-166

2.5.2.15 SM-Submit-Ack

This optional field is sent from the MT to the TE to convey the information to be inserted into the SMS-SUBMIT-REPORT RP-ACK TPDU sent by the SC to the MT as defined in GSM  03.40.

8

7

6

5

4

3

2

1

0

0

0

1

0

0

0

0

octet 1

SM-SUBMIT-ACK information element identifier

Length of SMS-SUBMIT-REPORT RP-ACK Field

octet 2

03.40 SMS-SUBMIT-REPORT RP-ACK

octets 3-166