6 Service Centre functionality

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

In the present document, only the SC functionality related to the short message service between the SC and the MS is specified.

6.1 Service Centre capabilities

The SC should be capable of:

‑ submitting a short message to an MS, retaining the responsibility of the message until

1) the report has been received; or

2) the Validity‑Period expires.

‑ receiving a report from the PLMN;

‑ receiving a short message from an MS;

‑ returning a report to the PLMN for a previously received short message.

6.2 SC functional requirements

The detailed functionality of the SC is outside the scope of the present document, and is for the SC operator to define. However, the following functional requirements are mandatory for all SCs in order to support the SM‑TP (see clause 9) towards the PLMN:

1) To identify each SMS‑DELIVER sent to an MS in a unique way, a time stamp value is included in the field TP‑Service‑Centre‑Time‑Stamp, TP‑SCTS, of the SMS‑DELIVER. The time stamp gives the time when the message arrived at the SC with the accuracy of a second. If two or more messages to the same MS arrive at the SC within one second, the SC shall modify the time stamp of those messages in such a way that:

a) all messages to the MS contain different time stamps;

b) the modification of the time stamps is kept to a minimum.

2) The SC is only allowed to have one outstanding SMS‑DELIVER (i.e. a message for which a report has not been received) to a specific MS at a given time.

3) The SC shall be able to initiate overwriting of short messages previously received by the SC if requested by the same originating address (MS or any other source) by use of the same message type.

6.2.1 Subaddressing support

Support for subaddressing is an optional functional requirement for an SC. If it is supported, subaddressing information shall be conveyed from SME to SME according the following rules:

– A SME may send a SM with ‘*’s or ‘#’s included in the TP-DA field. The first ‘#’ encountered in TP-DA indicates where the address for SC 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.

– When the SC receives a SM to convey with such a subaddress information, it should deliver the SM to the destination SME with the same subaddress digits copied in the TP-OA field.

This subaddressing mechanism does not apply when the TON is alphanumeric

Example:

SME with number 987654321 sends a SM with TP-DA = 1234#56#789*

SME with number 1234 will receive the SM with TP-OA = 987654321#56#789*

6.2.2 Support for trigger SMS filtering for Tsms submissions

Support for trigger SMS filtering for Tsms submissions is an optional functional requirement for an SC as specified in 3GPP TS 23.682 [48]. If it is supported, the SC uses the TP-Protocol-Identifier containing a Device Triggering Short Message code as an indication of trigger SMS and compare list of known SME against the SME in the RP-OA field of received short message to filter and block all short messages that do not originate from trusted SMEs.

6.3 SC EMS Extended Object Data Request Command Feature

An SME has the ability of determining which data formats within the Extended Object IE are supported by a specific terminal. The SC has the option of supporting this feature using an SMS-DELIVER PDU. This SMS-DELIVER PDU shall contain the EMS Data Format Delivery Request IE, and be marked for automatic deletion by the mobile station.