4 Requirements
22.1423GPPRelease 17TSValue Added Services (VAS) for Short Message Service (SMS) requirements
4.1 High Level Requirements
The VAS-SMS shall be implemented without influencing the existing SMS service.
The VAS-SMS shall be implemented without depending on the terminal’s capability.
Users shall be able to register, activate, deactivate, withdraw and reconfigure VAS-SMS via the UE, or web portals.
The VAS-SMS shall be designed and implemented in a way to provide users who joined the services one coherent and identical user experience, regardless of the SM flow and SM scenario (e.g. messages to and from applications, MO-MT in an in network and MT from Foreign Network).
Provisioning of VAS-SMS by one operator should not depend on the support of other operators i.e. originating or terminating VAS-SMS services should be independently.
4.2 Overall Service Requirements
4.2.1 Management of Service Information
4.2.1.1 Capabilities provided to the user
The VAS-SMS shall be able to support a request from an application to query/change the choice of services for a subscriber.
The VAS-SMS shall be able to support a request from an application to query/change the subscriber’s preferences for a certain service, for example:
i) To add or delete or modify a subscriber’s filtering conditions by which VAS-SMS can refuse some of the subscriber’s incoming messages.
ii) To modify a subscriber’s signature that will be appended to an SM sent from the subscriber.
iii) To modify a subscriber’s forwarding address that substitutes for the subscriber’s original receiving address.
4.2.1.2 Capabilities provided to the network
The VAS-SMS shall be able to support a request to query/change the subscriber’s information, for example:
i) To get the detail information about the subscriber’s service.
ii) To add or delete a subscriber’s service information.
The VAS-SMS shall be able to support a request to query the handling results of the subscription service.
4.2.1.3 Capabilities provided to authorized third party
The VAS-SMS shall be able to support a request from an application to modify the contents that will be appended to an SM, for example:
i) to load or unload a particular content provided by the third party
ii) to associate a content with a particular subscriber or a type of subscribers
iii) to define the trigger for inclusion or change of such content
Note: The management of VAS4SMS service is out of scope of 3GPP standardisation.
4.2.2 Short Message processing
The VAS-SMS should be able to deal with the content of an SM, for example:
i) To insert content (as agreed with the subscriber, or as agreed with a third party and authorized by the subscriber) into the original SM and form a new SM (e.g. append the signature to the SM, append the content as provided by the third party, …).
ii) To compile an SM by containing operator’s information (e.g. construct a delivery report).
iii) To use certain words in an SM as the filtering criteria.
The VAS-SMS should be able to convert the format of an SM into other formats (e.g. email, WAP message, etc).
4.2.3 Short Message Forwarding
It shall be supported that users can set certain conditions (e.g., different time periods) for message forwarding. There are no significant delays to any part of the service.
With the advent of SM forwarding there is also the issue of how to handle the situation when a user by mistake sets forwarding to wrong number (a number that is in use). Ideally a recipient should be capable of stopping the delivery of such SM to its own address. As a minimum the recipient’s operator should be capable of identifying forwarded SM and stop delivery. Infinite forwarding loops needs to be prevented and the maximum number of times the SM is forwarded should be limited.
SM Forwarding service should support forwarding to numbers of both the operator as well as other operators.
It shall be possible to Notify a recipient upon activation of the service and only upon his approval activate the service for the user.
There may be no relation between SM Forwarding service and Voice Call Forwarding service.
4.2.4 Short Message Forwarding multiple subscriptions
It may be supported that an operator can set a group of subscriptions for which SM are forwarded to the active/last activated subscription of that group, under the condition that the delivery address of the SM is associated to a subscription of that group and that address is not registered on the network.
4.2.5 Short Message filtering
It shall be supported that users can set certain conditions for message filtering.
4.2.6 Short Message receipt
It shall be supported that the callee can configure the content of an additional receipt SM for different callers, so the standard Status Report may be accompanied by a newly generated SM with the content provided by the operator.
4.2.7 Short Message Network Storage
It should be possible for the operator to support Short Message Network Storage to allow users to store the messages in the network.
It should be possible for users to store the messages in the network based on their personal settings (e.g. store all sent & received messages, store the messages from/to particular users, store the messages sent & received in a specified period of time etc).
It should be possible for users to store and manage the messages for their preference (e.g. users can set different folders to store different sort of messages, therefore it is convenient to inquire the stored messages based on message sort or key words).
It should be possible for the operator to ensure all relevant information of the messages stored in the network are consistent with that displayed to users, e.g. content of the messages, sender/recipient, sending/receiving time, etc.
It shall be supported that user can pre-set certain conditions for storage. The storage condition includes all sent messages, all received messages, messages sent to or received from one or more special phone numbers and so on.
It should be possible for the operator to prevent storage of configuration SM, notifications (e.g. voice mail, SM delivery notifications).
It shall be supported that users can transfer the messages stored in the message depository to any other mobile phone.
It shall be supported that users can inquire the messages stored in the message depository according to certain query conditions (e.g., short message receiver, short message sender, key words etc.).
It shall be supported that users can manage the stored messages via a website, and it shall be possible for the user to set access right for other users ( e.g. read only , read and download etc), in this way, other users are able to inquire his stored messages through a link to the website after valid authentication.
In case of multiple delivery attempts SM will be copied only once regardless of the number of delivery attempts.
It shall be possible to combine concatenated SM to single Message in the Network store or alternatively indicate in the message that it is part of concatenated SM.
The Short Message Network Storage service shall prevent duplicate storage message as a result of failure in transmission of the original SM.
Messages should be stored in the Network Storage regardless of the user availability and as soon as the original SM is being processed in the SMSC.
4.2.8 Short Message to multiple destinations
It shall be able to support inclusion of multiple recipients in a message when a user sends a single message to multiple individuals.
It should be possible for all recipients of the message to be aware of other recipients.
It should be possible for a recipient to choose to whom the reply message is sent, i.e. to the original sender and to other recipients of the original message.
It shall be supported that a user can include multiple destination addresses in a message. The recipient except those addresses displaying information is blocked shall receive information on all recipients of the message.
It shall be supported that each recipient of the message can send a message back to all recipients of the original message.
4.2.9 Short Message Virtual Private Network (VPN)
Sending messages to local numbers based on the dialling plan should be supported. There shall be no significant delays to any part of the service.
4.2.10 Short Message Auto Reply
It shall be possible that users can activate the SM Auto Reply Service to be active for different time periods. In addition it shall be possible to configure the system to reply only once to each sender in a predefined period of time.
It shall be possible for users to configure and manage their Automatic Reply messages, e.g. edit and delete the content of the message.
It shall be possible for users to set different Automatic Reply messages to different senders.
Auto reply to auto reply loops need to be prevented.
4.2.11 Short Message Personal Signature
The SM Personal Signature Service shall support certain conditions configured by users or control system wide (e.g., append personal signature depending on the original short message length, append personal signature to certain destinations). There shall be no significant delays to any part of the service.
4.2.12 Short Message Deferred Delivery
The SM Deferred delivery shall support the following delivery time options:
– Relative timing – The text will include information as for the of how many more days, hours, minutes shall pass before the message shall be delivered.
– Absolute timing – The text will include information indicating of the specific Date and Time for the message to be delivered
The SM Deferred Delivery Service shall support all type of languages
The SM Deferred Delivery Service shall support concatenated messages
There shall be no significant delays to any part of the service.
4.2.13 Management and control of network based repository
VAS-SMS should be able to provide following capabilities to support network based repository:
– The VAS-SMS should allow configuring in such a way that certain sent or received messages of a particular user can be stored persistently in a network based repository.
– The VAS-SMS should be able to support a request from SMS-SC to persistently store a sent message in a network based repository at the time of sending.
– The VAS-SMS should be able to support a request from an application to upload certain messages into a network based repository for persistent storage.
– The VAS-SMS should be able to support a request from an application to retrieve/delete certain messages stored in a network based repository
– The VAS-SMS should be able to support a request from an application to view the list of messages and related attributes (e.g. sender, recipient, date/time, etc) in a network based repository
4.2.14 Addressing
The VAS-SMS should support different addressing formats to identify the sender and recipient; it should support both MSISDN[3] and e-mail addressing schemes[4].
A short number should be supported. This number should be unique within VPN where it is used.
The VAS-SMS should support an alpha-numeric addressing format (similar to specified in [2]).
The VAS-SMS should be able to submit one message to multiple recipients.
The VAS-SMS should be able to support the request to hide the sender’s or other recipients’ addresses.