5.2 SMS offline charging scenarios
32.2743GPPCharging managementRelease 17Short Message Service (SMS) chargingTelecommunication managementTS
5.2.1 Basic principles
SMS offline charging functionality is based on SMS Nodes reporting chargeable events associated with SM transactions.
The SMS offline charging applies to the SMS-SC and IP-SM-GW.
SMS offline charging uses the Diameter Offline Charging as specified in TS 32.299 [4].
Event based charging applies, with reporting achieved by sending Charging Data Request [event] to the CDF.
SMS transactions are collected independently by the SMS Node , or on completion handling at SMS Node (enhanced submission) .
5.2.2 Rf message flows
5.2.2.0 Introduction
The different scenarios below focus on the different message exchanges from/to the SMS Node and the corresponding message flows between the SMS Node and the CDF.
The sequence of messages exchanged between the SMS Node and the other nodes are described with generic names
(i.e SMS submit, SMS deliver), to reflect SMS reception or sending by/from the SMS Node, independently from the protocol conveying the SMS.
Each message flow is applicable to different Network scenario, which are referred-to by relevant TSs.
The SMS Nodes for which these message flows apply are the SMS-SC and IP-SM-GW.
5.2.2.1 SMS Submission
Figure 5.2.2.1.1 describes the scenario where UE or a third party application originates SMS-MO destined to a recipient UE:
Figure 5.2.2.1.1: Offline charging – SMS submission to SMS Node
0) Initial procedures: see applicable Network scenario.
1) The SMS Node receives a "SMS Submit" incoming message originated by a UE or a third party application.
2) The SMS Node returns "SMS Submit Answer" with appropriate result associated to the reception of the SM: successfully received by SMS-SC or failed due to error at SMS Node.
3) The SMS Node triggers a Charging Data Charging Data Request with Operation Type indicating EVENT_RECORD to record successful or unsuccessful reception of the SM, with originator identified as UE or as a third party application, depending on the scenario.
NOTE: In the scenario where a third party application is originator, sending application identification to the CDF allows to apply accurate charging model of Termination scenario, i.e. recipient UE to be charged for the delivered SM, instead of originator or both parties.
4) The CDF creates a SMO CDR and acknowledges the reception of the data.
5) Forward SMS per applicable Network scenario.
The table 5.2.2.1.1 describes the correspondence between the message in this scenario, and the message in the different Network scenario for which it is applicable.
Table 5.2.2.1.1: Messages mapping
|
Message |
Message in Network scenario |
Reference |
|---|---|---|
|
1. SMS submit |
10a. Message Transfer |
TS 23.040[7] Figure 18a): Successful short message transfer attempt |
|
3. Message |
TS 23.204[8] Figure 6.3: Successful encapsulated Short Message origination procedure |
|
|
3. Delivery report |
TS 23.204[8] Figure 6.5: Delivery report procedure |
|
|
2. SMS submit answer |
10b. Delivery report |
TS 23.040[7] Figure 18a): Successful short message transfer attempt |
|
4. Accepted |
TS 23.204[8] Figure 6.3: Successful encapsulated Short Message origination procedure |
|
|
4. Accepted |
TS 23.204[8] Figure 6.5: Delivery report procedure |
|
|
5. Forward SMS |
Not applicable |
TS 23.040[7] Figure 18a): Successful short message transfer attempt |
|
6. Forward short message |
TS 23.204[8] Figure 6.3: Successful encapsulated Short Message origination procedure |
|
|
6. Delivery report |
TS 23.204[8] Figure 6.5: Delivery report procedure |
5.2.2.2 SMS Delivery
Figure 5.2.2.2.1 describes the scenario where SMS Node originates SM transfer towards the receiving party.
Figure 5.2.2.2.1: Offline charging SMS Transfer from SMS Node
0) "SMS to deliver" optionally received by SMS Node in order to deliver a MT SMS towards the UE: see applicable Network scenario.
1) The SMS Node decides to forward "SMS Deliver" message towards the receiving party, as a first attempt (based on step 0) or due to internal trigger for a retry delivery of a previously failed and stored SM.
2) The SMS Node forwards the "SMS Deliver" message towards the receiving party.
3) The SMS Node receives "SMS Deliver Answer" message as the delivery success or failure of the SM transfer attempt.
4) The SMS Node triggers a Charging Data Request[Event] to record successful or unsuccessful result of SM delivery.
5) The CDF creates a SMT CDR and acknowledges the reception of the data.
The table 5.2.2.2.1 describes the correspondence between the message in this scenario, and the message in the different Network scenario for which it is applicable.
Table 5.2.2.2.1: Messages mapping
|
Message |
Message in Network scenario |
Reference |
|---|---|---|
|
1. SMS to deliver |
Not applicable |
TS 23.040[7] Figure 15a): Successful short message transfer attempt via the MSC or the SGSN |
|
4. Forward short message |
TS 23.204 [8] Figure 6.4: Successful encapsulated Short Message termination procedure |
|
|
9. Submit report |
TS 23.204[8] Figure 6.3: Successful encapsulated Short Message origination procedure |
|
|
3. SMS deliver |
1a. Message transfer |
TS 23.040[7] Figure 15a): Successful short message transfer attempt via the MSC or the SGSN |
|
6. Message |
TS 23.204[8] Figure 6.4: Successful encapsulated Short Message termination procedure |
|
|
10. Submit report |
TS 23.204[8] Figure 6.3: Successful encapsulated Short Message origination procedure |
|
|
4. SMS deliver answer |
Not shown |
TS 23.040[7] Figure 15a): Successful short message transfer attempt via the MSC or the SGSN |
|
9. OK |
TS 23.204 [8] Figure 6.4: Successful encapsulated Short Message termination procedure |
|
|
13. OK |
TS 23.204[8] Figure 6.3: Successful encapsulated Short Message origination procedure |
5.2.2.3 Delivery Report
Delivery Report or Status Report (SC informing the originating UE of the delivery outcome of a previously submitted short message) issued by the SMS Node uses the same procedures as the "SMS Delivery from the SMS Node" described within clause 5.2.2.2, as it is contained within a new SM.
5.2.2.4 Device Triggering using T4
5.2.2.4.1 SMS submission to SMS-SC for Device Triggering
Figure 5.2.2.4.1.1 describes the scenario where the MTC-IWF submits a request to SMS-SC for SM transfer towards the UE for Device Triggering purpose.
Figure 5.2.2.4.1.1: Offline charging – SMS submission to SMS-SC for Device Triggering
1) The SMS-SC receives an incoming "Device Trigger Request" from an MTC-IWF over T4, destined to a UE recipient.
2) The SMS-SC returns "Device Trigger Answer" with appropriate result associated to the reception of the trigger request: successfully received by SMS-SC or failed due to error at SMS-SC.
3) The SMS-SC triggers a Charging Data Request with Operation Type indicating EVENT_RECORD to record successful or unsuccessful reception of the SM from the MTC-IWF, with originator identified as SCS Identity.
4) The CDF creates a SC- DVT-T4 CDR and acknowledges the reception of the data.
5.2.2.4.2 SMS Delivery from SMS-SC for Device Triggering
Figure 5.2.2.4.2.1 describes the scenario where SMS-SC originates the SMS Device Triggering transfer towards the UE.
Figure 5.2.2.4.2.1: Offline charging – SMS delivery for Device Triggering
1) The SMS-SC decides to forward "SMS Deliver" message towards the receiving party, as a first attempt upon device trigger request received from MTC-IWF, or due to internal trigger for a retry delivery of a previously failed and stored SM for Device Triggering, or internal trigger for a first attempt of a previously stored SM.
2) The SMS-SC forwards the "SMS Deliver" message towards the receiving party.
3) The SMS-SC receives "SMS Deliver Answer" message as the delivery success or failure of the SM transfer attempt.
4) The SMS-SC triggers a Charging Data Request[Event] to record successful or unsuccessful result of SM delivery, including a value for "Device Triggering indication".
5) The CDF creates a SC-SMT CDR and acknowledges the reception of the data.
6) The SMS-SC sends "Delivery Report Request" to MTC-IWF with appropriate result associated to the successful delivery of the device trigger to the UE.
7) The MTC-IWF acknowledges by sending "Delivery Report Answer".
5.2.2.4.3 SMS Device Triggering Delivery Report
The SMS Device Triggering Delivery Report corresponds to the SMS-SC reporting the Delivery Report of Device Trigger to the MTC-IWF in the scenario described in clause 5.2.2.4.2. The Delivery Report itself is not a trigger for a charging event.
5.2.2.4.4 SMS submission to SMS-SC for Device Triggering – Replace procedure
Figure 5.2.2.4.4.1 describes the scenario where the MTC-IWF submits a request to SMS-SC for a replace procedure of Device Triggering:
Figure 5.2.2.4.4.1: Offline charging – SMS submission to SMS-SC for replace Device Triggering
1) The SMS-SC receives an incoming "Device Trigger Request" indicating "Replace" from an MTC-IWF over T4.
2) If the SMS-SC determines the trigger message identified by the External Identifier or MSISDN, SCS Identifier, and old trigger reference number in the received Device Trigger Replace message, is pending at SMS-SC, the new trigger message replaces the previous one. If no trigger message is pending this corresponds to a failed replace procedure.
3) The SMS-SC returns "Device Trigger Answer" with appropriate result of the successful or unsuccessful replace procedure.
4) The SMS-SC triggers a Charging Data Request[Event] to record successful or unsuccessful result of the replace procedure.
5) The CDF creates a SC-DVT-T4 CDR and acknowledges the reception of the data.
6) In case of successful replace, the new SM to be delivered uses the same procedure as per clause 5.2.2.4.2.1.
5.2.2.4.5 SMS submission to SMS-SC for Device Triggering – Recall procedure
Figure 5.2.2.4.5.1 describes the scenario where the MTC-IWF submits a request to SMS-SC for a recall procedure for Device Triggering:
Figure 5.2.2.4.5.1: Offline charging – SMS submission to SMS-SC for recall Device Triggering
1) The SMS-SC receives an incoming "Device Trigger Request" indicating "Recall" from an MTC-IWF over T4.
2) The SMS-SC determines the trigger message identified by the External Identifier or MSISDN, SCS Identifier, and old trigger reference number in the received Device Trigger Recall message, is pending at SMS-SC. The stored trigger message is deleted.
3) The SMS-SC returns "Device Trigger Answer" with appropriate result of the recall procedure.
4) The SMS-SC triggers a Charging Data Request[Event] to record successful or unsuccessful result of the recall procedure.
5) The CDF creates a SC-DVT-T4 CDR and acknowledges the reception of the data.
5.2.2.5 Offline charging error cases – Diameter procedures
The Offline Charging error cases in Diameter (Accounting) related procedures associated to Charging Data Request /Response, from SMS node as network element are specified in TS 32.299 [4] clause 6.1.3.
5.2.2.6 MSISDN-less SMS MO via T4
5.2.2.6.1 Introduction
The message flows associated to the MSISDN-less SMS MO via T4, illustrate the triggers occurring in the SMS-SC Node. As specified in TS 23.682 [17], the SMS delivery procedures to SMS-SC and SMS delivery report from SMS-SC are per TS 23.040 [12], therefore involving SMS-GMSC/SMS-IWMSC depending on the scenario. However, per this TS 23.040 [12], the interface between the SMS-GMSC/SMS-IWMSC and the SMS-SC is out of scope of 3GPP, therefore SMS-GMSC/SMS-IWMSC are assumed as internal to SMS-SC for the charging flows with triggers description.
5.2.2.6.2 MSISDN-less SMS MO via T4 – successful case
Figure 5.2.2.6.2.1 describes the scenario where MSISDN-less UE originates SMS-MO destined to a recipient SCS/AS using MSISDN-less SMS MO via T4 procedure:
Figure 5.2.2.6.2.1: Offline charging MSISDN-less SMS MO via T4 – successful case
1) The SMS-SC receives a "SMS Submit" incoming message originated by a MSISDN-less UE to deliver small data to SCS/AS.
2) The SMS-SC sends the "MO payload delivery Request" message to the MTC-IWF address (as pre-configured in the SMS-SC for this SCS/AS), with the SMS payload and the destination SME address (long/short code of the SCS/AS).
3) The MTC-IWF retrieves the external ID from the HSS (based on the IMSI of the UE and application port ID).
4-5) The MTC-IWF forwards the SMS to the SCS/AS (received destination SME), and receives the successful or failure answer.
6) The MTC-IWF returns a success or failure delivery indication to SMS-SC, along with the external identifier associated to this transaction.
7) The SMS-SC triggers a Charging Data Charging Data Request with Operation Type indicating EVENT_RECORD to record successful or unsuccessful delivery of the SM.
8) The CDF creates a SC-SMO-T4 CDR and acknowledges the reception of the data.
9) The SMS-SC indicates success/failure back to UE.
5.2.2.6.3 MSISDN-less SMS MO via T4 – error cases
5.2.2.6.3.1 MSISDN-less SMS MO via T4 – failure at submission to SMS-SC
Figure 5.2.2.6.3.1.1 describes the scenario where MSISDN-less UE originates SMS-MO destined to a recipient SCS/AS using MSISDN-less SMS MO via T4 procedure, and failure at submission to SMS-SC:
Figure 5.2.2.6.3.1.1: Offline charging MSISDN-less SMS MO via T4 – failure at submission
1) The SMS-SC receives a "SMS Submit" incoming message originated by a MSISDN-less UE to deliver small data to SCS/AS.
2) Failure in handling the submitted SMS-MO in the SMS-SC.
3) The SMS-SC triggers a Charging Data Charging Data Request with Operation Type indicating EVENT_RECORD to record the unsuccessful delivery of the SM.
4) The CDF creates a SC-SMO-T4 CDR and acknowledges the reception of the data.
5) The SMS-SC indicates the failure back to UE.
5.2.2.6.3.2 MSISDN-less SMS MO via T4 – failure at the MTC-IWF
Figure 5.2.2.6.3.2.1 describes the scenario where MSISDN-less UE originates SMS-MO destined to a recipient SCS/AS using MSISDN-less SMS MO via T4 procedure, and failure at the MTC-IWF:
Figure 5.2.2.6.3.2.1; Offline charging MSISDN-less SMS MO via T4 – failure at the MTC-IWF
1) The SMS-SC receives a "SMS Submit" incoming message originated by a MSISDN-less UE to deliver small data to SCS/AS.
2) The SMS-SC sends the "MO payload delivery Request" message to the MTC-IWF address (as pre-configured in the SMS-SC for this SCS/AS), with the SMS payload and the destination SME address (long/short code of the SCS/AS).
3) Failure in handling the submitted SMS-MO in the MTC-IWF.
4) The MTC-IWF returns the failure delivery indication to SMS-SC.
5) The SMS-SC triggers a Charging Data Charging Data Request with Operation Type indicating EVENT_RECORD to record the unsuccessful delivery of the SM.
6) The CDF creates a SC-SMO-T4 CDR and acknowledges the reception of the data.
7) The SMS-SC indicates the failure back to UE.
5.2.3 CDR generation
5.2.3.0 Triggers for SMS CDR generation
SMS related CDRs (i.e. SC-SMO, SC-SMT, ISM-SMO, ISM-SMT, SC-SMO-T4 and SC-DVT-T4 CDRs) are used to collect charging information related to individual Charging Data Request [event]. A single CDR is generated by the CDF for each event, and subsequently transfered to the Charging Gateway Function (CGF).
5.2.3.1 Triggers for SMS CDR charging information collection
The triggers for CDR creation are described in clause 5.2.3.0.
5.2.3.2 Triggers for SMS CDR charging information addition
The triggers for CDR creation are described in clause 5.2.3.0.
5.2.3.3 Triggers for SMS CDR closure
The triggers for CDR creation are described in clause 5.2.3.0.
5.2.4 Ga record transfer flows
Details of the Ga protocol application are specified in TS 32.295 [6].
5.2.5 Bsm CDR file transfer
Details of the Bsm protocol application are specified in TS 32.297 [5].