Content for TS 23.142 Word version: 17.0.0

4.1 General description of VAS-SMS service requirements 4.2 Operational requirements 5.1 Architectural requirements 5.2 Reference model 6.1 Activation/deactivation 6.2 Configuration
...

1 Scope p. 5

The present document describes the stage 2 of the VAS4SMS (Value Added Service for SMS). It includes:

The logic architecture;
The logic elements functionality;
The signaling flows;
The interaction with other features.

The service requirements of VAS4SMS are specified in TS 22.142.

The functionality and mechanism of SMS Service is defined in TS 23.040.

2 References p. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 22.142: "Value Added Services (VAS) for Short Message Service (SMS) requirements ".

[3]

TS 22.041: "Operator Determined Barring (ODB)".

[4]

TS 23.040: "Technical realization of the Short Message Service (SMS)".

[5]

TS 23.204: "Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access".

3 Definitions p. 5

3.1 Definitions p. 5

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

Loop prevention indication:

a indication set by VAS AS which indicates that a VAS service has been applied to generate this new message, e.g. message receipt, auto reply or message forwarding service. This indication is used by recipients VAS AS to check before also generating a new message to prevent loops.

Message transfer:

this term is used for SM transfer between MS and SMS Node.

Delivery report:

this term is used to deliver the status report of original SM between MS and SMS Node..

VAS check:

this term is used for the SMS Node to inquire the VAS AS if the VAS of user has activated.

VAS check response:

this term is used for the VAS AS to reply the result of VAS check.

Submit short message:

this term is used for the VAS AS to submit a new message to the SMS Node.

Submit short message sesponse:

this term is used for the SMS Node to acknowledge the submit short message from the VAS AS.

VAS delivery report:

this term is used for the SMS Node to deliver status report of the short message from the VAS AS.

VAS submittal report:

this term is used for the VAS AS to submit a general status report of the short message which generated by the VAS AS based on VAS delivery report.

Relay short message:

this term is used to transfer the short message between SMS Nodes.

Delivery status notification:

this term is used to deliver VAS submittal report between SMS Nodes.

4 VAS-SMS service requirements p. 6

4.1 General description of VAS-SMS service requirements p. 6

As defined in TS 22.142, the VAS4SMS is an operator specific service by which an operator enables the subscriber to experience some value-added service features for SMS.

VAS4SMS features that were defined in stage 1 include:

Short Message Forwarding
Short Message Forwarding Multiple Subscriptions
Short Message Filtering
Short Message Receipt
Short Message Network Storage
Short Message to Multiple Destinations
Short Message Virtual Private Network (VPN)
Short Message Auto Reply
Short Message Personal Signature
Short Message Deferred Delivery

VAS4SMS should not negatively affect the normal SMS communication between calling and called parties.

The service subscriber is able to subscribe to the VAS4SMS service, activate (or de-activate) the service, and update the settings, e.g., to change by configure the personalized service related information. The personalized service information can consist of message signature, the forwarding destination address and message contents for auto reply, etc.

The VAS4SMS subscriber is able to refine the VAS4SMS behaviour with configured rules, e.g. time, the identity of the calling party, the SMS forwarding service is able to act according to the rules.

VAS4SMS is either a terminating network or originating network service. That is, VAS4SMS can be used by the calling and called subscribers.

In general, services offered by the sender's VAS4SMS occur prior to the SMS delivering to the recipient's operation.

4.2 Operational requirements p. 7

4.2.1 VAS-SMS Provision/withdrawal p. 7

4.2.1.1 General p. 7

The VAS4SMS may be provided after prior arrangement with the service provider.

The VAS4SMS may be provided/withdrawn upon the subscriber's request or for administrative reasons.

4.2.1.2 Requirements on the originating network side p. 7

A VAS4SMS application server in the originating network is required to be under the control of the SMS-SC that is serving a calling subscriber who has activated VAS4SMS.

4.2.1.3 Requirements on the terminating network side p. 7

A VAS4SMS application server in the terminating network is required to be under the control of the SMS-Route that is serving a called subscriber who has activated VAS4SMS.

5 Architecture and Interface p. 7

5.1 Architectural requirements p. 7

The network architecture defined for VAS SMS should have less impact on pre-Rel 8 realization of short message service. The VAS SMS solution shall be able to be deployed independently of the pre-Rel 8 services. VAS SMS shall not break pre-Rel 8 services.

5.2 Reference model p. 7

5.2.1 Logical network architecture p. 7

Copy of original 3GPP image for 3GPP TS 23.142, Fig. 5.2.1.1: Logical network architecture for VAS4SMS

Figure 5.2.1.1: Logical network architecture for VAS4SMS
(⇒ copy of original 3GPP image)

5.2.2 Functional entities p. 8

The main functional entities involved in the VAS SMS services provisioning depicted in Figure 5.2.1.1 are described as follows.

5.2.2.1 VAS AS (VAS SMS Application Server) p. 8

The VAS AS is an entity in user's HPLMN of which the main requirement with respect to handling of the VAS4SMS messages is the necessary service logic handling.

The VAS AS informs the SMS Node whether or not it takes over the handling of a short message. The VAS AS will use a SMS Node for delivery of new or modified messages.

The VAS AS informs the SMS Node about the outcome of its short message handling.

VAS AS may receive the delivery report of the VAS4SMS messages generated by it from SMS Node

If the delivery of SMS is failed, VAS AS may re-send/resubmit the VAS4SMS messages for several times, subject to operator's configuration

5.2.2.2 SMS node p. 8

SMS Node may be the integration of standard SMS Functional elements defined in TS 23.040 depending on HPLMN (MO or MT): SMS-IWMSC, SMS-GMSC, SMS-SC or SMS Router.

Besides standard SMS functionalities described in TS 23.040 the SMS Node may support:

storage of the user subscription indication for the VAS4SMS
triggering a short message to VAS AS, if a user has VAS4SMS subscription
receiving a short message from VAS AS which is generated based on a previously triggered short message
submitting a short message which comes from VAS AS to the PLMN
receiving a report from PLMN and forwarding it to VAS AS
receiving a report from VAS AS

In case the communication between the SMS Node and VAS AS fails, the SMS Node proceeds as if the user hasn't subscribed the VAS4SMS.

5.2.2.3 Service Portal Function (SPF) p. 8

The SPF provides the means to VAS SMS subscription, activation & deactivation, configuration. The detailed information for these operations is described in clause 6. After a user subscribing a VAS4SMS, the portal should support the capability to synchronize the user setting information to VAS AS.

5.2.2.4 Billing and Charging Function (BCF) p. 8

BCF plays the role of receiving the call detail record (CDR) information from the VAS AS.

The other function entities in Figure 5.2.1.1 shall follow TS 23.040, which is outside the scope of this specification.

5.2.3 Interfaces p. 8

As illustrated in Figure 5.2.1.1, following interfaces are defined:

Rf-a: Rf-a is the interface between VAS AS and SMS Node. The VAS AS shall be able to influence and impact the SMS procedure on behalf of the services and it uses Rf-a interface to communicate with SMS Node.The SMS Node shall decide whether the information related to an incoming SMS is needed to send to the VAS AS and VAS AS shall make the SMS Node aware of any resulting activity. Rf-a shall also support to transfer the delivery result between VAS AS and SMS Node.
Rf-b: Rf-b is the interface between two SMS Nodes. The Rf-b interface is used for message transferring between two PLMSs.
Rf-c: Rf-c is the interface between VAS AS and Charging and Billing Function (BCF). The Rf-c is used for the VAS AS to transfer the CDR information to the BCF.
Rf-d: Rf-d is the interface between VAS AS and Service Portal Function (SPF). Rf-d is used to synchronize the user setting and subscription information from SPF to VAS AS

6 VAS-SMS service provisioning, activation & deactivation, configuration p. 9

6.1 Activation/deactivation p. 9

The VAS-SMS service is activated at provisioning and deactivated at withdrawal.

A subscriber can subscribe all the VAS-SMS service features as a whole or make the subscription to every feature separately, which is subject to operator's policy. When a VAS-SMS service is activated, a subscriber can specify some configuration for each subscribed service feature, such as the destination address which short messages shall be forwarded to.

After a subscriber has activated their VAS-SMS service, all short messages related to him shall be handled according to his service configuration.

6.2 Configuration p. 9

Different methods may be provided for configuration of VAS-SMS service, e.g. such as short message, IVR and etc. It is out of the scope of this document to specify the configuration procedure itself.