5 Architecture and Interface
23.1423GPPInterface and signalling flowRelease 17TSValue-added Services for SMS (VAS4SMS)
5.1 Architectural requirements
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
5.2.1 Logical network architecture
Figure 5.2.1.1 Logical network architecture for VAS4SMS
NOTE: Other SMS related elements (MSC/SGSN etc.) behavior is according to 3GPP TS 23.040[4].
5.2.2 Functional entities
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)
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
SMS Node may be the integration of standard SMS Functional elements defined in 3GPP TS 23.040[4] depending on HPLMN (MO or MT): SMS-IWMSC, SMS-GMSC, SMS-SC or SMS Router.
Besides standard SMS functionalities described in TS 23.040 [4] 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)
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)
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 3GPP TS 23.040[4], which is outside the scope of this specification.
5.2.3 Interfaces
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