5 MMS charging principles and scenarios

32.2703GPPCharging managementMultimedia Messaging Service (MMS) chargingRelease 18Telecommunication managementTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 MMS charging principles

5.1.0 Introduction

The MMS R/S collects charging information for each MM transaction that crosses the relevant reference points defined in TS 22.140 [200]. The chargeable events that trigger the collection of charging information on the applicable reference points are identical for MMS offline and online charging and are specified below. The use of the events to generate CDRs (offline charging) or Credit-Ccontrol requests (online charging) are described in clause 5.2 for offline charging and in clause 5.3 for online charging, respectively.

In line with the requirements laid down in TS 22.140 [200] and TS 23.140 [201] the MMS R/S collects charging information such as:

– the destination and source addresses applied for an MM;

– identification of the MMS R/S(s) involved in the MM transaction;

– the amount and type of user data transmitted in MO and MT directions for the transfer of MM; i.e. the size of the MM and its components;

– storage duration; i.e. the time interval when a MM is saved on a non-volatile memory media;

– identification of the bearer resources used for the transport of the MM; i.e. the identity of the network and the network nodes;

– in scenarios involving a VASP, the charging information describes the identification of the VASP and the amount of user data sent and received between the MMS R/S and the VASP.

– in scenarios involving the MSCF, additional information supplied by the MSCF.

The information listed above is captured for use cases in relation to:

– MM submission;

– MM retrieval;

– MM forwarding;

– transactions involving the MMbox;

– transactions involving a VASP.

Refer to TS 23.140 [201] for further details on the above MM transactions.

The following scenarios can be distinguished in MMS charging:

– Combined Originator and Recipient MMS R/S. This scenario covers the case where the Originator MMS R/S and the Recipient MMS R/S are identical, which implies that that particular MMS R/S handles both MM submission and MM retrieval.

– Distributed Originator and Recipient MMS R/S. This scenario covers the case of the Originator MMS R/S and the Recipient MMS R/S being two different entities, where the Originator MMS R/S handles MM submission and the Recipient MMS R/S handles MM retrieval.

– MMBox management. MMBox is a logical entity of the MMS R/S that allow to support the persistent network-based storage of the MMs. This feature is an extension of the MM1 interface that enables a MMS User Agent to store, retrieve and delete incoming and submitted MMs.

– VASP transactions. MMS VAS Application offers value added services to the MMS Users. The MMS VASP are able to interact with the MMS R/S via the MM7 interface using transactions similar to those of the MM1 interface i.e. submission, reception, delivery-report, read-reply report, etc.

These scenarios all pertain to atomic actions related to MMs, e.g. submission, retrieval, storage, deletion, etc., implying that MMS only uses event based charging, as specified in TS 32.240 [1] (i.e. session based charging is not applicable for MMS). The following subclauses further describe the above scenarios and illustrate the conditions for the various types of chargeable events based on MMs crossing the reference points identified in TS 23.140 [201] (MM1, MM4 and MM7). The labels in the message flows identify the chargeable events in relation to the particular reference point.

5.1.1 Combined OOriginator and Recipient MMS R/S

This scenario, as depicted in figure 5.1.1.1, covers the case where the Originator MMS R/S and the Recipient MMS R/S are identical, which implies that that particular MMS R/S handles both MM submission and MM retrieval.

Figure 5.1.1.1: Chargeable event overview for combined case

Table 5.1.1.2: Trigger point overview for combined MMS R/S

Trigger point	Trigger name
C1	Originator MM1 Submission
C2	Recipient MM1 Notification Request
C3	Recipient MM1 Notification Response
C4	Recipient MM1 Retrieval
C5	Recipient MM1 Acknowledgement
C6	Originator MM1 Delivery Report
C7	Recipient MM1 Read Reply Recipient
C8	Originator MM4 Read Reply Originator
C9	Recipient MM1 Cancellation (see note 2)
C10	Recipient MM1 Deletion
Any time between C1 to C8	Originator MM Deletion
NOTE 1: Chargeable events for MM submission, retrieval and cancellation are triggered by the MMS R/S responding to MM1_submit.REQ and MM1_retrieve.REQ, rather than upon receiving those requests and receiving a response to MM1_Cancel.RES rather than upon submitting this request NOTE 2: MM1 Cancellation is triggered by receiving an MM7_extended_cancel.REQ.

5.1.2 Distributed Originator and Recipient MMS R/S

This scenario, as depicted in figure 5.1.2.1, covers the case of the Originator MMS R/S and the Recipient MMS R/S being two different entities, where the Originator MMS R/S handles MM submission and the Recipient MMS R/S handles MM retrieval.

Figure 5.1.2.1: Chargeable event overview for distributed case

Table 5.1.2.2 : Trigger type overview for the Originator MMS R/S

Trigger point	Trigger name
O1	Originator MM1 Submission
O2	Originator MM4 Forward Request
O3	Originator MM4 Forward Response
O4	Originator MM4 Delivery Report
O5	Originator MM1 Delivery Report
O6	Originator MM4 Read Reply Report
O7	Originator MM1 Read Reply Originator
Any time between O1… O7	Originator MM Deletion
NOTE: Chargeable events for MM submission are triggered by the MMS R/S responding to MM1_submit.REQ, rather than upon receiving those requests.

Table 5.1.2.3: Trigger type overview for the Recipient MMS R/S

Trigger point	Trigger name
R1	Recipient MM4 Forward
R2	Recipient MM1 Notification Request
R3	Recipient MM1 Notification Response
R4	Recipient MM1 Retrieval
R5	Recipient MM1 Acknowledgement
R6	Recipient MM4 Delivery Report Request
R7	Recipient MM4 Delivery Report Response
R8	Recipient MM1 Read Reply Recipient
R9	Recipient MM4 Read Reply Report Request
R10	Recipient MM4 Read Reply Report Response
R11	Recipient MM1 Cancellation (see note 2)
R12	Recipient MM1 Deletion
Anytime after R2	Recipient MM Deletion
NOTE 1: Chargeable events for MM retrieval and cancellation are triggered by the MMS R/S responding to MM1_retrieve.REQ, rather than upon receiving those requests and receiving a response to MM1_Cancel.RES rather than upon submitting this request NOTE 2: MM1 Cancellation is triggered by receiving an MM7_extended_cancel.REQ.

5.1.3 MMBox management

MMBox is a logical entity of the MMS R/S that allows to support the persistent network-based storage of the MMs.
This feature is an extension of the MM1 interface that enables the MMS User Agent to store, retrieve and delete incoming and submitted MMs. For further detailed description of "Persistent Network-Based Storage" see TS 23.140 [201].

This scenario, as depicted in figure 5.1.3.1, covers the MM transactions related to MMBox usage and the associated chargeable events in the affected MMS R/S.

Figure 5.1.3.1: Chargeable event overview for MMBox management

Table 5.1.3.2: Trigger type overview for MMBox management

Trigger point	Trigger name
M1	MMBox MM1 Upload
M2	MMBox MM1 Store
M3	MMBox MM1 View
M4	MMBox MM1 Delete
NOTE: Chargeable events for MM Upload, Store, View and Delete are triggered by the MMS R/S responding to these requests, rather than upon receiving them.

5.1.4 VASP transactions

MMS VAS Application offers value added services to the MMS Users. The MMS VASP are able to interact with the MMS R/S via the MM7 reference point using transactions similar to those of the MM1 interface i.e. submission, reception, delivery-report, read-reply report, etc.

The VASP may provide service codes that contain billing information which may be transferred to the MMS R/S and passed directly to the billing system without intervention. In addition, the VASP may provide an indication to the MMS R/S which party is expected to be charged for an MM submitted by the VASP, e.g. the sending, receiving, both parties or neither.

This scenario, as depicted in figure 5.1.4.1, covers the VASP related MM transactions and the associated chargeable events in the affected MMS R/S.

Figure 5.1.4.1: Chargeable event overview for VASP transactions

Table 5.1.4.2: Trigger type overview for VASP transactions

Trigger point	Trigger name
V1	MM7 Deliver Request
V2	MM7 Deliver Response
V3	MM7 Submission
V4	MM7 Delivery Report Request
V5	MM7 Delivery Report Response
V6	MM7 Read Reply Report Request
V7	MM7 Read Reply Report Response
V8	MM7 Replacement
V9	MM7 Cancellation
V10	MM7 Extended Replacement
V11	MM7 Extended Cancellation
NOTE: Chargeable events for MM7 submission, replacement and cancellation are triggered by the MMS R/S responding to these requests, rather than upon receiving them.

5.2 MMS offline charging scenarios

5.2.1 Basic principles

MMS offline charging implies the generation of CDRs of various types by the involved MMS R/S(s). As explained in clause 5.1, only event based charging applies to MMS, i.e. there is no use of session based charging in the MMS R/S.
In line with the principles for event based charging laid down in TS 32.240 [1], the relationship between chargeable events and charging events is 1:1, and the relationship between charging events and CDRs is also 1:1.

The chargeable event triggers are defined in clause 5.1.1 to 5.1.4 above and are identified by the labels within the figures 5.1 to 5.4 (message flows) in relation to the particular MMS reference point. As can be seen from these figures, the chargeable events relate to transactions at the MM1, MM4 and MM7 reference points.

An open Rf or Ga interface is not specified for MMS in the 3GPP standards, hence no charging events (Rf message flows) are specified in clause 5.2.2.
In clause 5.2.3, CDR generation is described in relation to the chargeable event triggers specified in clause 5.1, given that there is a 1:1 relation all the way from chargeable event to CDR type as explained in the first paragraph above. However, due to the absence of a standard Ga interface for MMS, from the 3GPP specifications perspective these CDRs are only visible in CDR files crossing the Bm interface.

5.2.2 Rf message flows

Not applicable, as the separation of the CTF and CDF is not in the scope of the MMS charging standards.
Refer to clause 4.2 for further information.

NOTE: Vendors may nevertheless implement a separate CTF and CDF for MMS charging.
In this case, it is recommended that the approach chosen conforms to the principles and protocol applications specified in TS 32.299 [50].

5.2.3 CDR generation

For MMS, the Ga interface is not applicable, as the separation of the CDF and CGF is not in the scope of the MMS charging specifications. I.e. the following CDR types are visible only in the CDR files transferred from the MMS R/S embedded CGF to the BD via the Bm interface.

NOTE: If vendors choose to implement the Ga interface for MMS, then it is recommended that the approach chosen conforms with the CDRs specified in this section and the Ga protocol conventions laid down in
TS 32.295 [54].

5.2.3.1 Combined Originator and Recipient MMS R/S case

The chargeable events for the case of a combined Originator and Recipient MMS R/S are depicted in figure 5.1.1.1 and further listed in table 5.1.1.1. Due to the fact that only event based charging applies to MMS (see clause 5.2.1), these chargeable events translate 1:1 into the CDR types listed in table 5.2.3.1.1 below.

The first row in table 5.2.3.1.1 refers to the trigger labels in figure/table 5.1.1.1.
The second row identifies the associated CDR type. The content of these CDR types is specified in clause 6.

Table 5.2.3.1.1: Record type overview for combined MMS R/S

Record trigger	C1	C2	C3	C4	C5	C6	C7	C8	C9	C10	Any time between C1 .. C8
Record type	O1S	R1NRq	R1NRs	R1Rt	R1A	O1D	R1RR	O1R	R1C	RMD	OMD

5.2.3.2 Distributed Originator and Recipient MMSR/S case

The chargeable events for the case of distributed Originator and Recipient MMS R/Ss are depicted in figures 5.1.2.2/3 and further listed in table 5.1.2.1. Due to the fact that only event based charging applies to MMS (see clause 5.2.1), these chargeable events translate 1:1 into the CDR types listed in tables 5.2.3.2.1/2 below.

The first row in the tables refers to the trigger labels in figure/table 5.1.2. The second row identifies the associated CDR type. The content of these CDR types is specified in clause 6.

Table 5.2.3.2.1: Record type overview for the Originator MMS R/S

Record trigger	O1	O2	O3	O4	O5	O6	O7	Any time between O1.. O7
Record type	O1S	O4FRq	O4FRs	O4D	O1D	O4R	O1R	OMD

Table 5.2.3.2.2: Record type overview for the Recipient MMS R/S

Record trigger

R10

R11

R12

Anytime after R2

Record type

R4F

R1NRq

R1NRs

R1Rt

R1A

R4DRq

R4DRs

R1RR

R4RRq

R4RRs

R1C

RMD

5.2.3.3 MMBox related CDRs

The chargeable events for the MMBox management are depicted in figure 5.1.3.1 and further listed in table 5.1.3.2.
Due to the fact that only event based charging applies to MMS (see clause 5.2.1), these chargeable events translate 1:1 into the CDR types listed in table 5.2.3.3.1 below.

The first row in table 5.2.3.3.1 refers to the trigger labels in figure/table 5.1.3.1.
The second row identifies the associated CDR type. The content of these CDR types is specified in clause 6.

Table 5.2.3.3.1 : Trigger type overview for MMBox management

Record trigger	M1	M2	M3	M4
Record type	Bx1U	Bx1S	Bx1V	Bx1D

5.2.3.4 CDRs related to VASP transactions

The chargeable events for the VASP transactions are depicted in figure 5.1.4.1 and further listed in table 5.1.4.2.
Due to the fact that only event based charging applies to MMS (see clause 5.2.1), these chargeable events translate 1:1 into the CDR types listed in table 5.2.3.4.1 below.

The first row in table 5.2.3.4.1 refers to the trigger labels in figure/table 5.1.4.1.
The second row identifies the associated CDR type. The content of these CDR types is specified in clause 6.

Table 5.2.3.4.1: Record type overview for VASP transactions

Record trigger	V1	V2	V3	V4	V5	V6	V7	V8	V9	V10	V11
Record type	MM7S	MM7DRq	MM7DRs	MM7C	MM7R	MM7DRRq	MM7DRRs	MM7RRq	MM7RRs	MM7ER	MM7EC

5.2.4 Ga record transfer flows

Not applicable, as the separation of the CDF and CGF is not in the scope of the MMS charging standards.
Refer to clause 4.2 for further information.

NOTE: Vendors may nevertheless implement a separate CDF and CGF for MMS charging. In this case, it is recommended that the approach chosen conforms to the principles and protocol applications specified in TS 32.295 [54].

5.2.5 Bm CDR file transfer

The integrated CGF of the MMS R/S transfers the CDR files to the BD as described in TS 32.297 [52].
In MMS, both fully qualified partial CDRs (FQPC) and reduced partial CDRs (RPC), as specified in TS 32.240 [1] may be supported on the Bm interface. In line with TS 32.240 [1], the support of FQPCs is mandatory, the support of RPCs is optional. For further details on the Bm protocol application refer to TS 32.297 [52].

5.3 MMS online charging scenarios

MMS online charging uses the Credit Control (CC) application as specified in TS 32.299 [50].

5.3.1 Basic principles

MMS charging may use the Immediate Event Charging (IEC) principle or the Event Charging with Unit Reservation (ECUR) principle as specified in TS 32.299 [50]. The chargeable events for subscriber charging are associated with MM submission and MM retrieval.

An implementation shall use only one principle for all chargeable events throughout a given instance of providing MMS service to the user, i.e. either IEC or ECUR.

The units used for quota shall be service specific and based on an MM.

5.3.2 Ro message flows

5.3.2.0 General

The message flows described in the present document specify the charging communications between MMS R/S and the Online Charging System (OCS) for different charging scenarios. The MMS messages associated with these charging scenarios are shown primarily for general information and to illustrate the charging triggers that are also used for MMS offline charging.

5.3.2.1 MM submission

Figure 5.3.2.1.1 shows the Credit-Control transactions that are required between MMS R/S and OCS during the MM submission. In this scenario the originator MMS User Agent is the party to charge for the MM submission.

Figure 5.3.2.1.1: MMS online charging scenario for MM submission

5.3.2.2 MM retrieval

Figures 5.3.2.2.1 and 5.3.2.2.2 show the Credit-Control transactions that are required between MMS R/S and OCS during the MM retrieval. In this scenario the Recipient MMS User Agent is the party to charge for the reception.

NOTE: For IEC, if the retrieval process is not successful for any reason (e.g. MM1_retrieve_Ack is not received) and another MM1_retrieve_req is received for the same message (identified by the Message ID), it is OCS logic to determine whether the subsequent requests are charged.

Figure 5.3.2.2.1 : MMS online charging for MM retrieval using IEC

Figure 5.3.2.2.2: MMS online charging scenario for MM retrieval using ECUR

5.3.2.3 MMS reports

5.3.2.3.1 Delivery report

Editor’s note: The completion of this clause is ffs.

5.3.2.3.2 Read report

Editor’s note: The completion of this clause is ffs.

5.4 MMS converged online and offline charging scenarios

5.4.1 Basic principles

5.4.1.1 General

Converged charging may be performed by the MMS Node interacting with CHF using Nchf specified in TS 32.290 [2] and TS 32.291 [3]. In order to provide the data required for the management activities outlined in TS 32.240 [1] (Credit-Control, accounting, billing, statistics etc.), the MMS Node shall be able to perform converged charging for each of the MMS transactions.

The MMS Node shall be able to perform convergent charging by interacting with CHF, for charging data related to MMS. The Charging Data Request and Charging Data Response are exchanged between the MMS Node and the CHF, based on PEC, IEC or ECUR scenarios specified in TS 32.290 [2]. The Charging Data Request is issued by the MMS Node towards the CHF when certain conditions (chargeable events) are met.

The contents and purpose of each charging event that triggers interaction with CHF, as well as the chargeable events that trigger them, are described in the following sub-clauses.

A detailed formal description of the converged charging parameters defined in the present document is to be found in TS 32.291 [3].

A detailed formal description of the CDR parameters defined in the present document is to be found in TS 32.298 [51].

The chargeable events or messages exchanged between the MMS Node and the other nodes are described with generic names (i.e., MMS submit, MMS retrieve), to reflect MMS sending or retrieval by/from the MMS Node, independently from the protocol conveying the MMS.

5.4.1.2 Applicable Triggers in the MMS Node

5.4.1.2.1 General

When a charging event is issued towards the CHF, it includes details such as Subscriber identifier (e.g., SUPI).

Each trigger condition (i.e., chargeable event) defined for the MMS converged charging functionality, is specified with the associated behaviour when they are met.

When an MMS IS sent or retrieved, and the converged charging is activated, the MMS Node a Charging Data Request [Initial] towards the CHF to get authorization to start in ECUR mode. In IEC mode, the Charging Data Request [Event] is sent towards the CHF.

Table 5.4.1.2.1 summarizes the set of default trigger conditions and their category which shall be supported by the MMS Node. For "immediate report" category, the table also provides the corresponding Charging Data Request [Initial, Event, Termination] message sent from MMS Node towards the CHF.

Table 5.4.1.2.1: Default Trigger conditions in MMS Node

Trigger Conditions	Trigger level	Default category	CHF allowed to change category	CHF allowed to enable and disable	Message when "immediate reporting" category
MMS Submit request	–	Immediate	Not Applicable	Not Applicable	IEC: Charging Data Request [Event]
MMS Retrieve request	–	Immediate	Not Applicable	Not Applicable	IEC: Charging Data Request [Event] ECUR: Charging Data Request [Initial]
MMS Retrieve acknowledge	–	Immediate	Not Applicable	Not Applicable	PEC: Charging Data Request [Event] ECUR: Charging Data Request [Termination]

Trigger Conditions

Trigger level

Default category

CHF allowed to change category

CHF allowed to enable and disable

Message when "immediate reporting" category

MMS Submit request

–

Immediate

Not Applicable

IEC: Charging Data Request [Event]

MMS Retrieve request

–

Immediate

Not Applicable

IEC: Charging Data Request [Event]

ECUR: Charging Data Request [Initial]

MMS Retrieve acknowledge

–

Immediate

Not Applicable

PEC: Charging Data Request [Event]

ECUR: Charging Data Request [Termination]

For converged charging, the following details of chargeable events and corresponding actions in the MMS Node are defined in Table 5.4.1.2.2:

Table 5.4.1.2.2: Chargeable events and their related actions in MMS Node

Chargeable event	Conditions	MMS Node action
MMS Submit request		IEC: Charging Data Request [Event]
MMS Retrieve request		IEC: Charging Data Request [Event] ECUR: Charging Data Request [Initial] with a possible request quota for later use
MMS Retrieve acknowledge		PEC: Charging Data Request [Event] ECUR: Charging Data Request [Termination], indicating that charging session is terminated

Chargeable event

Conditions

MMS Node action

MMS Submit request

IEC: Charging Data Request [Event]

MMS Retrieve request

IEC: Charging Data Request [Event] ECUR: Charging Data Request [Initial] with a possible request quota for later use

MMS Retrieve acknowledge

PEC: Charging Data Request [Event]

ECUR: Charging Data Request [Termination], indicating that charging session is terminated

The CDR generation mechanism processed by the CHF upon receiving Charging Data Request [Event, Initial, Termination] issued by the MMS Node for these chargeable events, is specified in clause 5.4.3.

5.4.1.3 CHF selection

The CHF to be used by the MMS Node can be:

– Discovered via NRF.

– Locally provisioned.

The option depends on Operator’s policies.

When CHF selection by MMS Node is performed via NRF based discovery, the CHF can be discovered based on the UE identifier.

5.4.2 Message flows

5.4.2.1 Introduction

The different scenarios below focus on the different messages from/to the MMS Node and corresponding interaction with the CHF, based on scenarios specified in clause 5.3.2.5.4.2.2 MM submission

Editor’s Note: The use of PEC is FFS.

Figure 5.4.2.2.1 describes the scenario where an MMS is submitted to the to MMS Node for IEC mode

Figure 5.4.2.2.1: MMS submission to MMS Node for IEC

1. Initial procedures: see applicable flows.

2. The MMS Node receives "MMS Submit request" message from an originator MMS user agent.

2ch-a. The MMS Node sends Charging Data Request [Event] to CHF for the MMS submission.

2ch-b. The CHF creates a CDR for this MMS submission.

2ch-c. The CHF acknowledges by sending Charging Data Response [Event] to the MMS Node.

3. The MMS Node returns "MMS Submit response" with appropriate result.

The table 5.4.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.4.2.2.1: Messages mapping

Message	Message in Network scenario	Reference
2. MMS Submit request	MM1_submit_Req
3. MMS Submit response	MM1_submit_Res

Editor’s Note: Which message and reference to use in the table is FFS.5.4.2.3 MM retrieval

Figure 5.4.2.3.1 describes the scenario where an MMS is retrieved from the MMS Node for IEC mode

Figure 5.4.2.3.1 MMS retrieval from MMS Node for IEC

1. Initial procedures: see applicable flows.

2. The MMS Node receives "MMS Retrieve request" message from a recipient MMS user agent

2ch-a. The MMS Node sends Charging Data Request [Event] to CHF for the MMS submission.

2ch-b. The CHF creates a CDR for this MMS retrieval.

2ch-c. The CHF acknowledges by sending Charging Data Response [Event] to the MMS Node.

3. The MMS Node returns "MMS Retrieve response" with appropriate result.

4. The MMS Node receives "MMS Retrieve acknowledge" with the result.

Figure 5.4.2.3.2 describes the scenario where an MMS is retrieved from the MMS Node for ECUR mode.

Figure 5.4.2.3.2: MMS retrieval from MMS Node for ECUR

1. Initial procedures: see applicable flows.

2. The MMS Node receives "MMS Retrieve request" message from a recipient MMS user agent.

2ch-a. The MMS Node sends Charging Data Request [Initial] to CHF for authorization.

2ch-b. The CHF opens CDR for this MMS retrieval.

2ch-c. The CHF acknowledges by sending Charging Data Response [Initial] to the MMS Node

3. The MMS Node returns "MMS Retrieve response" with appropriate result.

4. The MMS Node receives "MMS Retrieve acknowledge" with the result.

4ch-a. The MMS Node sends Charging Data Request [Termination] to the CHF for terminating the charging associated with MMS retrieval.

4ch-b. The CHF closes the CDR for this MMS retrieval.

4ch-c. The CHF acknowledges by sending Charging Data Response [Termination] to the MMS Node.

Figure 5.4.2.3.3 describes the scenario where an MMS is retrieved from the MMS Node for PEC mode7

Figure 5.4.2.3.3 MMS retrieval from MMS Node for PEC

1. Initial procedures: see applicable flows.

2. The MMS Node receives "MMS Retrieve request" message from a recipient MMS user agent

3. The MMS Node returns "MMS Retrieve response" with appropriate result.

4. The MMS Node receives "MMS Retrieve acknowledge" with the result.

4ch-a. The MMS Node sends Charging Data Request [Event] to CHF for the MMS submission.

4ch-b. The CHF creates a CDR for this MMS retrieval.

4ch-c. The CHF acknowledges by sending Charging Data Response [Event] to the MMS Node.

The table 5.4.2.3.1 describes the correspondence between the message in all scenarios, and the message in the different Network scenario for which it is applicable.

Table 5.4.2.3.1: Messages mapping

Message	Message in Network scenario	Reference
2. MMS Retrieve request	MM1_retrieve_Req
3. MMS Retrieve response	MM1_retrieve_Res
4. MMS Retrieve acknowledge	MM1_retrieve_Ack

Editor’s Note: Which message and reference to use in the table is FFS.

5.4.3 CDR generation

5.4.3.1 Introduction

The CHF CDRs for MMS charging are generated by the CHF to collect charging information.

The following clauses describe in detail the conditions for generating, opening and closing the CHF CDR, which shall be supported by the CHF.

5.4.3.2 Triggers for CHF CDR

5.4.3.2.1 General

A MMS charging CHF CDR is used to collect charging information related to MMS chargeable events for PEC, IEC and ECUR.

5.4.3.2.2 Triggers for CHF CDR generation

A CHF CDR is generated by the CHF for each received Charging Data Request [Event].

5.4.3.2.3 Triggers for CHF CDR opening

A CHF CDR shall be opened when the CHF receives Charging Data Request [Initial].

5.4.3.2.4 Triggers for CHF CDR closure

The CHF CDR shall be closed when the CHF receives Charging Data Request [Termination].

5.4.4 Ga record transfer flows

Details of the Ga protocol application are specified in TS 32.295 [54].

5.4.5 Bm CDR file transfer

Details of the Bm protocol application are specified in TS 32.297 [52].