The reply procedures specified in this Annex should be followed by a mobile station when replying to a short message, i.e. when generating a MO SM in response to a received MT SM, addressed to the originator of that MT SM. The main purpose of this Annex is to specify how the MS selects the service centre for delivering that MO SM: an arbitrary SME may only be reached by submitting the reply SM to a specific SC, known to be able of delivering to that SME.

The reply procedures in clauses 5 and 6 of this Annex should be followed by every MS which fulfils the following criteria:

1. The MS automatically selects the value for the RP-Destination-Address parameter in RP-MO-DATA, or the MS has the SC address within the SM-RL entity. (That is to say: the human user is not obliged to manually key in the SC address for every MO short message).
2. The MS or an application within it supports some form of replying to a MT SM with a MO SM. (That is to say: in the process of generating the reply MO SM, any reference whatsoever, implicit or explicit, is made to the original MT SM).
3. The replying support of (2) is to be equally available towards every SME.

When an SME submits an SM to an SC for delivery, it may request that the SC sets the TP-Reply-Path parameter in the SM to be delivered. If the submitting SME is an MS, the reply path requesting procedure; in clause 4 of this Annex may be applied. However, an SC may support the reply procedures without supporting the reply path requesting procedure; in that case, the SC sets the TP-Reply-Path parameter on another basis, which must be the case if the SM originates from an SME which is not an MS.

An originating SME submits an original SM to an original SC, which delivers the original MT SM to a replying MS. The replying MS sends back a reply MO SM, a MO SM which is generated (automatically or by human operations) in response to the original MT SM, and which is addressed to the originating SME. If the originating SME is an MS, the original MT SM is submitted within an SMS-SUBMIT PDU; we say that reply path is requested if the TP-Reply-Path parameter is set in the SMS-SUBMIT PDU of the original MT SM. We say that reply path exists if the TP-Reply-Path parameter was set in the SMS-DELIVER PDU of the original MT SM; we say that reply path does not exist otherwise. The replying MS may have a default SC which is normally used for delivering all the MO short messages originated from the replying MS. Alternatively, a human user or automatic application may specify a selected SC for delivering a particular SM (thus the term selected SC refers to an SC address selected for one short message only).

The discussion in this clause applies to cases when the originating SME is a mobile station only. The reply procedures discussed in the clauses to follow this one are independent of the type of the originating SME. The reply path is requested by the originating SME (an MS) by setting the TP-Reply-Path parameter in the SMS SUBMIT PDU of the original SM. If the original SC supports reply path requesting for the originating SME (an MS), it shall take notice of the TP-Reply-Path parameter in the SMS-SUBMIT PDU and set the TP-Reply-Path parameter in the SMS-DELIVER PDU of the original MT SM towards the replying MS. Hence, reply path exists for the replying MS towards the originating SME (an MS).

When a replying MS receives an original MT SM, it then has:

1. originating SME = TP-Originating-Address in the SMS-DELIVER PDU,
2. original SC = RP-Originating-Address in RPS-MT-DATA, and
3. reply path exists/reply path does not exist = TP-Reply-Path in SMS-DELIVER PDU (set/not set).

According to clause 5, the replying MS knows if:

1. reply path exists; or
2. reply path does not exist.

We then specify that when submitting the reply MO SM, the replying MS should use parameters as follows: In case (2b), it is allowed to use the original SC or the default SC, but then there is no guarantee that the original/default SC shall deliver the reply MO SM. (The original SC may refuse to deliver, if the replying MS is not its subscriber; the default SC may be unable to deliver, if it has no access path to the originating SME.) Requirement (3a) states that the case (a), reply path exists, holds for one reply MO SM only (per original MT SM).

The specification in this Annex supports the following way of replying. The original MT SM and the reply MO SM are delivered by the same SC, the original SC. This principle maximizes the probability that the SC can e.g. route the reply MO SM to the proper data network for reaching the originating SME; this principle is a must, if the originating SME is integrated within the original SC. If the original SC by any means whatsoever knows that it is both willing and able to deliver one (potential) reply MO SM, it may indicate this fact by setting the TP-Reply-Path parameter in the original MT SM. The original SC thus commits itself to delivering one reply MO SM; let us call this reply delivery commitment. One reason for the SC to make the reply delivery commitment may be the reply path requesting procedure specified in clause 4 on this Annex. The reply path commitment is not valid forever, but the original SC may have e.g. a time limit for maintaining this commitment.

The Phase 2 mobile stations should support the procedures in this Annex (if they fulfil the criteria in clause 2 of it). Yet, Phase 1 mobile stations, too, may apply steps (1) and (2a) in clause 6 of this Annex, i.e. reply via the original SC, automatically or manually (by choosing selected SC = original SC), despite the fact that the TP-Reply-Path parameter shall be ignored by them. The delivery of the reply MO SM cannot be guarantied in this case, yet the possibility of delivery may be improved (especially if the originating SME is not an MS).

As the consequence of the replying procedures specified in this Annex, all SMEs and applications within them may assume that replying from all mobile stations is always possible, provided that the mobile stations do support the proper replying mechanism itself (human response in context with the original MT SM, automatic replying by an application, application level protocols, etc.).