5 Charging function requirement

32.2903GPP5G SystemCharging managementRelease 18Services, operations and procedures of charging using Service Based Interface (SBI)Telecommunication managementTS

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

5.1 Offline charging scenario

5.1.1 Basic principles

Basic principles for offline charging are defined in TS 32.240 [1].

5.1.2 Charging scenarios

5.1.2.1 Introduction

Two basic scenarios are used:

– Event based charging;

– Session based charging.

Both scenarios may generate CDR files, which may then be transferred to the network operator’s BD for the purpose of subscriber billing and/or inter-operator accounting.

5.1.2.2 Scenarios

5.1.2.2.1 Event based charging

Figure 5.1.2.2.1.1 shows a scenario for Post Event Charging, (PEC) where the NF (CTF) interacts with the CHF after the service delivery.

Figure 5.1.2.2.1.1: Post Event Charging

1) Request for resource usage: A request for session establishment is received in the NF (CTF).

2) Content/Service Delivery: the NF (CTF) delivers the content/service.

3) Charging Data Request [Event]: The NF (CTF) the CTF generates charging data related to the delivered service and sends the request for the CHF to store related charging data for CDR generation purpose.

4) Create CDR: the CHF stores received information and creates a CDR related to the service.

5) Charging Data Response [Event]: The CHF informs the NF (CTF) on the result of the request.

5.1.2.2.2 Session based charging

Figure 5.1.2.2.2.1 shows a scenario for Offline session based charging where the NF (CTF) interacts with the CHF.

Figure 5.1.2.2.2.1: Offline charging

1) Request for service delivery and start of service delivery: A request for session establishment is received in the NF (CTF).

2) Charging Data Request [Initial]: The NF (CTF) sends the request to inform the CHF about the service to be started.

3) Open CDR: the CHF opens a CDR related to the service.

4) Charging Data Response [Initial]: The CHF informs the NF (CTF) on the result of the request and optionnaly provides the usage reporting triggers applicable to the service.

5) Content/Service Delivery: the NF (CTF) delivers the content/service.

6) Usage Reporting Trigger: the NF (CTF) generates charging data related to service delivered, based on a trigger for usage reporting is met.

7) Charging Data Request [Update]: the NF (CTF) sends the request for reporting the related charging data to the CHF.

8) Update CDR: the CHF updates the CDR with charging data related to the service.

9) Charging Data Response [Update]: The CHF informs the NF (CTF) on the result of the request.

10) Content/Service Delivery: the NF (CTF) delivers the content/service.

11) Service release: the service is released.

12) Charging Data Request [Termination]: the NF (CTF) sends the request to the CHF, for charging data related to the service termination.

13) Close CDR: the CHF closes the CDR with charging data related to the service termination.

14) Charging Data Response [Termination]: The CHF informs the NF (CTF) on the result of the request.

5.2 Online charging scenario

5.2.1 Basic principles

Basic principles for online charging are defined in TS 32.240 [1].

5.2.2 Charging scenarios

5.2.2.1 Introduction

The following basic scenarios are used:

1 Immediate Event Charging

a) Decentralized Unit Determination and Centralized Rating

b) Centralized Unit Determination and Centralized Rating

c) Decentralized Unit Determination and Decentralized Rating

2 Event charging with Unit Reservation

a) Decentralized Unit Determination and Centralized Rating

b) Centralized Unit Determination and Centralized Rating

c) Decentralized Unit Determination and Decentralized Rating

3 Session charging with Unit Reservation

a) Decentralized Unit Determination and Centralized Rating

b) Centralized Unit Determination and Centralized Rating

c) Decentralized Unit Determination and Decentralized Rating

The combination of Centralized Unit Determination with Decentralized Rating is not possible.

5.2.2.2 Scenarios

The scenarios described in TS 32.299 [50], clauses 5.2.2.1, 5.2.2.2 and 5.2.2.3, apply with the CHF acting as an OCF.

5.2.3 Void

5.3 Converged Charging scenario

5.3.1 Basic principles

When offline charging and online charging are applicable to a service delivery, the charging information of both offline charging (without quota management) and online charging (with quota management) can be provided in a single command. The triggering for reporting the charging information can be any triggers of the offline charging or online charging (deferred or immediate triggers).

The invocation of the Charging Data Request for start of service, in case there is no valid quota for the rating group, can be done in either blocking mode or non-blocking mode:

– blocking mode: the service delivery shall not start before its authorization from CHF;

– non-blocking mode: the service delivery may start before its authorization from CHF.

For invoking the ConvergedCharging service with quota management, the ConvergedCharging service will operate in decentralized unit determination with the provided amounts of the Quota Requested information element otherwise if no amount is included in the Quota Requested information element, the ConvergedCharging service will operate in centralized unit determination and rating.

5.3.2 Charging scenarios

5.3.2.1 Introduction

Converged charging for both events and sessions between CTF and the CHF is performed as defined in TS 32.240 [1].

Two basic scenarios are used:

– Converged Event based charging;

– Converged Session based charging.

5.3.2.2 Event based charging

For Converged Event based Charging, he following cases are supported:

– Immediate Event Charging (IEC);

– Post Event Charging (PEC).

The scenario for Event based charging supported by IEC is shown in figure 5.3.2.2.1 with: Decentralized and Centralized Unit Determination, Centralized Rating configurationand user’s account balance deduction before service delivery, where the NF (CTF) may invoke converged charging service towards the CHF, prior to service delivery if needed.

Figure 5.3.2.2.1: IEC- Event based charging with Decentralized and Centralized Unit Determination, Centralized Rating

1) Request for resource usage: A request for session establishment is received in the NF (CTF). The service is configured to be authorized by the CHF to start.

2) Units Determination: the NF (CTF) determines the number of units depending on the service requested by the UE in "Decentralized Units determination" scenario.

3) Charging Data Request [Event, Units]: The NF (CTF) sends the request to the CHF for the service to be granted authorization, and to allow the number of units, if determined in item 2, to be rated and accounted.

4) Account, Rating Control: The CHF calculates the number of monetary units that represents the price and makes deduction of the calculated amount from user’s account balance based on the number of units requested or on internal unit determination, if the user’s credit balance is sufficient.

5) Create CDR: based on policies, the CHF creates a CDR related to the service.

6) Charging Data Response [Event, Units]: The CHF grants authorization to NF (CTF) for the service to start, with a number of granted units.

7) Granted Units Supervision: The service starts and the NF (CTF) monitors the consumption of the granted units.

8) Content/Service Delivery: the NF (CTF) delivers the content/service based on the number of units.

The scenario for Event based charging supported by PEC is described in figure 5.1.2.2.1.1.

5.3.2.3 Session based charging

For Converged Session based Charging, the following cases are supported:

– SCUR

– ECUR

Figure 5.3.2.3.1 shows a blocking mode scenario for Session based charging (SCUR) with: Unit Reservation, Decentralized and Centralized Unit Determination, Centralized Rating configuration, user’s account deduction, where the NF (CTF) invokes a converged charging service towards the CHF.

Figure 5.3.2.3.1: SCUR – Session based charging with Decentralized and Centralized Unit Determination, Centralized Rating

1) Request for service delivery: A request for session establishment is received in the NF (CTF). The service is configured to be authorized by the CHF to start.

2) Units Determination: the NF (CTF) determines the number of units depending on the service requested by the UE in "Decentralized Units determination" scenario.

3) Charging Data Request [Initial, Quota Requested]: The NF (CTF) sends the request to the CHF for the service to be granted authorization to start, and to reserve the number of units if determined in item 2.

4) Account, Rating, Reservation Control: the CHF rates the requests either based on the number of units requested or on internal unit determination, checks if corresponding funds can be reserved on the user’s account balance. If the account has sufficient funds, the CHF performs the corresponding reservations.

5) Open CDR: based on policies, the CHF opens a CDR related to the service.

6) Charging Data Response [Initial, Quota Granted]: The CHF grants authorization to NF (CTF) for the service to start, with the reserved number of units.

7) Granted Units Supervision: the NF (CTF) monitors the consumption of the granted units.

8) Start of service delivery: the NF (CTF) starts to deliver the content/service based on the reserved number of units.

9) Usage Reporting Trigger: the NF (CTF) generates charging data related to the service delivered that is not under quota management, based on a trigger for usage reporting is met.

10) Charging Data Request [Update, Unit Used]: the NF (CTF) sends the request for reporting the related charging data, including the used units, to the CHF.

11) Account, Rating Control: The CHF performs the reported usage process involving rating entity and user’s account balance.

12) Update CDR: based on policies, the CHF updates the CDR with charging data related to the service.

13) Charging Data Response [Update]: The CHF informs the NF (CTF) on the result of the request.

14) Quota management Trigger: A Trigger associated to Quota management is met. Units determination is performed when applicable.

15) Charging Data Request [Update, Unit Used, Quota Requested]: the NF (CTF) sends the request to the CHF, for more units to be granted for the service to continue, and reporting the used units.

16) Account, Rating, Reservation Control: The CHF performs the process related to the reported usage and the requested reservation, involving rating entity and user’s account balance.

17) Update CDR: based on policies, the CHF updates the CDR with charging data related to the service.

18) Charging Data Response [Update, Quota Granted]: The CHF grants quota to NF (CTF) for the service to continue, with the reserved number of units.

19) Content/Service Delivery: the NF (CTF) delivers the content/service based on the granted quota.

20) Session released: the session is released.

21) Charging Data Request [Termination, Unit Used]: the NF (CTF) sends the request to the CHF, for charging data related to the service termination with the final consumed units.

22) Account, Rating Control: The CHF performs the service termination process involving rating entity and user’s account balance.

23) Close CDR: based on policies, the CHF closes the CDR with charging data related to the service termination and the last reported units.

24) Charging Data Response [Termination]: The CHF informs the NF (CTF) on the result of the request.

Figure 5.3.2.3.2 shows a Non-blocking mode scenario for Session based charging (SCUR) with: Unit Reservation, Decentralized and Centralized Unit Determination, Centralized Rating configuration , user’s account deduction , where the NF (CTF) invokes a converged charging service towards the CHF.

NF (CTF) may use blocking mode instead when risk of quota overdraft is more important than latency.

Figure 5.3.2.3.2: SCUR – Session based charging with Decentralized and Centralized Unit Determination, Centralized Rating, immediate start of service delivery (Non-blocking mode)

1) Request for service delivery and start of service delivery: A request for session establishment is received in the NF (CTF). The NF (CTF) is configured to allow the service to be delivered.

2) Units Determination: the NF (CTF) determines the number of units depending on the service requested, in "Decentralized Units determination" scenario.

3) Charging Data Request [Initial, Unit Used, Quota Requested]: the NF (CTF) sends the request to the CHF to reserve the number of units if determined in step 2, it may also report the used units.

5) Open CDR: based on policies, the CHF opens a CDR related to the service.

6) Charging Data Response [Initial, Quota Granted]: the CHF grants the reserved number of units to NF (CTF).

7) Granted Units Supervision: The NF (CTF) monitors the consumption of the granted units.

8) Service delivery ongoing: the NF (CTF) continues to deliver the service.

9) Usage reporting trigger: the NF (CTF) generates charging data related to a service delivered that is not under quota management, based on that a trigger for service usage reporting is met.

10) Charging Data Request [Update, Unit Used]: the NF (CTF) reports the charging data related to service delivered, including the used units, to the CHF.

11) Account, Rating Control: the CHF uses the reported charging data to rate the usage and deduct the funds corresponding to the usage on the account balance.

12) Update CDR: based on policies, the CHF updates the CDR with charging data related to the service.

13) Charging Data Response [Update]: The CHF informs the NF (CTF) on the result of the request.

14 ) Quota management Trigger: A Trigger associated to Quota management is met. Units determination is performed when applicable.

15) Charging Data Request [Update, Unit Used, Quota Requested]: the NF (CTF) sends the request to the CHF, for more units to be granted for the service to continue, and reporting the used units.

16) Account, Rating, Reservation Control: same as step 4, with the option to also deduct the funds corresponding to the usage on the account balance.

17) Update CDR: based on policies, the CHF updates the CDR with charging data related to the service.

18) Charging Data Response [Update, Quota Granted]: The CHF grants quota to NF (CTF) for the service, with the reserved number of units.

19) Service delivery ongoing: the NF (CTF) continues to deliver the service.

20) Service release: the NF (CTF) is requested to end the service delivery and does this.

21) Charging Data Request [Termination, Unit Used]: the NF (CTF) sends the request to the CHF, for charging data related to the service termination with the final consumed units.

22) Account, Rating Control: the CHF performs the service termination process which involve using the reported charging data to rate the usage and deduct the funds corresponding to the usage on the account balance.

23) Close CDR: based on policies, the CHF closes the CDR with charging data related to the service termination and the last reported units.

24) Charging Data Response [Termination]: The CHF informs the NF (CTF)on the result of the request.

Figure 5.3.2.3.3 shows a scenario for Session based charging (ECUR) in Decentralized and Centralized Unit Determination, Centralized Rating configuration, where the NF (CTF) invokes a converged charging service towards the CHF, prior to service delivery if needed.

Figure 5.3.2.3.3: ECUR – Session based charging with – Decentralized and Centralized Unit Determination, Centralized Rating.

1) Request for resource usage: A request for session establishment is received in the NF (CTF). The service is configured to be authorized by the CHF to start.

2) Units Determination: the NF (CTF) determines the number of units depending on the service requested by the UE in "Decentralized Units determination" scenario.

5) Open CDR: based on policies, the CHF opens a CDR related to the service.

6) Charging Data Response [Initial, Quota Granted]: The CHF grants authorization to NF (CTF) for the service to start, with the reserved number of units.

7) Granted Units Supervision: The service starts and the NF (CTF) monitors the consumption of the granted units.

8) Content/Service Delivery: the NF (CTF) delivers the content/service based on the reserved number of units.

9) Charging Data Request [Termination, Unit Used]: the NF (CTF) sends the request to the CHF, for charging data related to the delivered service with the consumed units.

10) Account, Rating Control: The CHF performs the process for the delivered service involving rating entity and user’s account balance.

11) Close CDR: based on policies, the CHF closes the CDR with charging data related to the delivered service.

12) Charging Data Response [Termination]: The CHF informs the NF (CTF) on the result of the request.

5.3.2.4 Charging notification

The CHF can provide notifications to the NF (CTF), the NF (CTF) implicitly subscribes to these when it sends a Charging Data Request [Initial], i.e. there is no separate subscription request from the NF for notification.

Figure 5.3.2.4-1 shows a scenario for Session based charging with a notification from the CHF triggering a Charging Data Request [Update].

Figure 5.3.2.x.1: Session based charging – Notification with Re-authorization

1) Session based charging ongoing: there is a session based charging ongoing and there have at least been a Charging Data Request [Initial] sent from the NF (CTF) to the CHF, and the CHF have opened a CDR.

2) Event triggering notification: an event is detected in the CHF that requires a notification to be sent to the NF (CTF). In this scenario a request for triggering a Charging Data Request [Update, Quota Requested ] is sent, but also requests for Charging Data Request [Update] (without request for quota) is possible.

3) Charging Notify Request [Re-authorization]: the CHF sends the request to the NF (CTF), for a triggering of a Charging Data Request [Update, Quota Requested] i.e. Re-authorization.

4) Charging Notify Response: the NF (CTF) acknowledges the request by sending a response.

5) Charging Data Request [Update, Quota Requested]: the NF (CTF) sends the request to the CHF, to be granted with more unit for the service to continue, and also for reporting the used units.

6) Account, Rating, Reservation Control: the CHF performs the process related to the reported usage and the requested reservation, involving rating entity and user’s account balance.

7) Update CDR: based on policies, the CHF updates the CDR with charging data related to the service.

8) Charging Data Response [Update, Quota Granted]: the CHF grants quota to NF (CTF) for the service to continue, with the reserved number of units.

Figure 5.3.2.4.2 shows a scenario for Session based charging with a notification from the CHF triggering a Charging Data Request [Termination].

Figure 5.3.2.4.2: Session based charging – Notification with termination

3) Charging Notify Request [Termination]: the CHF sends the request to the NF (CTF), for a triggering of a Charging Data Request [Termination] i.e. the termination of the charging session.

4) Charging Notify Response: the NF (CTF) acknowledges the request by sending a response.

5) Charging Data Request [Termination]: the NF (CTF) sends the request to the CHF, for charging data related to the service termination with the final consumed units.

6) Account, Rating Control: the CHF performs the process related to the reported usage, involving rating entity and user’s account balance.

7) Close CDR: based on policies, the CHF closes the CDR with charging data related to the service.

8) Charging Data Response [Termination]: The CHF informs the NF (CTF) on the result of the request.

5.3.2.5 Switch between quota managed and not quota managed

When converged charging is used for a service delivery it is possible to in online charging to switch from quota management to quota management suspended, and in some cases back again.

Figure 5.3.2.5.1 shows a scenario for Session based charging (SCUR) with a suspension of quota management and resume of quota management.

Figure 5.3.2.5.1: SCUR – Session based charging with suspend and resume of quota management.

1) Request for resource usage: A request for session establishment is received in the NF (CTF). The service is configured to be authorized by the CHF to start.

2) Units Determination: the NF (CTF)) determines the number of units depending on the service requested by the UE in "Decentralized Units determination" scenario.

4) Account, Rating, Reservation Control: the CHF rates the requests and checks need for quota management. If not needed for the service at the moment a switch from online to offline type of charging is to be performed.

5) Open CDR: based on policies, the CHF opens a CDR related to the service.

6) Charging Data Response [Initial, Result Code]: The CHF grants authorization to NF (CTF) for the service to start, with a result code indicating that quota management is suspended.

7) Content/Service Delivery: the NF (CTF) delivers the content/service without quota management.

8) Usage Reporting Trigger: the NF (CTF) generates charging data related to the service delivered that is not under quota management, based on a trigger for usage reporting is met.

9) Charging Data Request [Update, Unit Used, Quota Requested]: the NF (CTF) sends the request to the CHF, for units to be granted making it possible to resume the quota management. It also reports the used units with an indication that these were used with quota management suspended.

10) Account, Rating, Reservation Control: The CHF performs the process related to the reported usage and checks if quota management should continue to be suspended or should be resumed. If needed for the service, CHF checks if corresponding funds can be reserved on the user’s account balance.

11) Update CDR: based on policies, the CHF updates the CDR with charging data related to the service.

12) Charging Data Response [Update, Quota Granted]: The CHF grants quota to NF (CTF) for the service to continue and with this indicating that quota management is to be resumed, with the reserved number of units.

13) Content/Service Delivery: the NF (CTF) delivers the content/service based on the granted quota.

14) Session released: the session is released.

15) Charging Data Request [Termination]: the NF (CTF) sends the request to the CHF, for charging data related to the service termination with the final consumed units.

16) Account, Rating Control: The CHF performs the service termination process involving rating entity and user’s account balance.

17) Close CDR: based on policies, the CHF closes the CDR with charging data related to the service termination and the last reported units.

18) Charging Data Response [Termination]: The CHF informs the NF (CTF) on the result of the request.

5.4 Other functionalities

5.4.1 Re-authorization

The CHF (NF Service Producer) may trigger a re-authorization request and the NF Service Consumer shall report quota usage. The reason for the quota being reported shall be notified to the CHF (NF Service Producer). This is described under charging notification procedure in clause 5.3.2.4.

The NF Service Consumer may receive a Charging Notify Request while waiting for a Charging Data Response from the CHF. In this case the NF Service Consumer shall not send a new Charging Data Request.

The NF Service Consumer may receive a Charging Notify Request while not waiting for any Charging Data Response from the CHF. In this case the NF Service Consumer shall send a new Charging Data Request.

5.4.2 Threshold based re-authorization triggers

The CHF (NF Service Producer) may optionally include an indication to the NF Service Consumer of the remaining quota threshold that shall trigger a quota re-authorization.

If received quota threshold based re-authorization triggers (i.e. timeQuotaThreshold, volumeQuotaThreshold, unitQuotaThreshold), the NF Service Consumer shall seek re-authorization for the quota when the quota contents fall below the supplied threshold. The NF Service Consumer allows the service to continue whilst the re-authorization is progress, until the remaining part had been used up.

5.4.3 Termination action

The CHF (NF Service Producer) may use the Final Unit Indication to indicate specify to the NF Service Consumer the behaviour on consumption of the final granted units, or zero units granted in the first place; this is known as termination action.

The NF Service Consumer should perform the action indicated in the Final Unit Indication, which may be to terminate, redirect or to restrict access, when any final granted units have been used. If the granted units contain no units it means that the action should be performed immediately.

If the action is terminate, then the NF Consumer may terminate all the services belonging to the rating group.

If the action is redirect, then the NF Consumer may redirect all access to the services belonging to the rating group to the destination indicated, if filter rules are provided it may also restrict the access towards the new destination.

If the action is restrict access, then the NF Consumer may restrict access to the services belonging to the rating group based on filter rules.

5.4.4 Service termination

The CHF (NF Service Producer) may determine that a service requires termination. The NF Service Producer may perform this termination synchronously if it has a request pending processing by returning response.

If the CHF (NF Service Producer) does not have a pending request (asynchronous), the NF Service Producer may trigger an abort notification to terminate the charging session. On reception of an abort notification, the NF consumer shall terminate the associated charging session by sending a Nchf_ConvergedCharging_Release. If the associated charging session is not currently active or NF consumer does not terminate the charging session for any other reason, the corresponding error response is returned.

The CTF (NF Service Consumer) may determine service termination. For session based charging the termination request shall include the used units if any. For event based charging there may be no used unit reported.

5.4.5 Trigger Mechanism

There are a number of mid-session service events, defined as triggers, which could affect the rating of the current service usage, e.g. QoS changes or end user location updates. The details for this these triggers are defined in the service specific document (middle tier TS). The relationship between service session and charging session is 1:1.

There are two levels of triggers: service session and rating group. The service session level triggers are applicable for all rating groups within a charging session, whereas a rating group level trigger is only applicable to that rating group. Any limit or threshold set on the service session level is the total limit for the service session including all the rating groups. The behaviour at trigger detection is specified by the middle tier TS.

Triggers enabled or disabled by default by the NF consumer, may be enabled or disabled by CHF in response to the NF consumer.

The CHF may enable one or more triggers at the NF consumer, by including them in the Triggers element. Each Triggers element can only contain one trigger of each type. The omitted triggers in the Triggers element shall be interpreted by the NF consumer as disabled. The enabled and disabled triggers setting at the NF consumer shall remain in effect until another Triggers element is received from the CHF for the service session or rating group. When the NF consumer receives a Triggers element it shall enable all triggers present in the Triggers element and disable all other triggers at the same level. The presence of the Triggers element without any trigger type in a response message allows CHF to disable all the triggers at the NF Consumer for service session or rating group.

NOTE: This removes the need for the CHF to send trigger information in every response message when they have not changed.

Two categories of chargeable events are identified:

– immediate report: chargeable events for which, when occurring, the current counts are closed and sent together with the charging data generated by the NF consumer towards the CHF in a Charging Data Request message. Counts indicating zero usage may be reported. New counts are started by the NF consumer.

– deferred report: chargeable events for which, when occurring, the current counts are closed and stored together with the charging data generated by the NF consumer. Counts indicating zero usage may be included. The stored counts will be sent to the CHF in next a Charging Data Request message. New counts are started by the NF consumer.

CHF may change the category of one or more triggers by using the Triggers element containing category information in the response message.

For the rating group: the rating group level triggers and category take precedence over the service session level triggers and category.

If there is a request for quota management outstanding for a rating group i.e., the request has not been responded to, any new request for quota management for the same rating group should be postponed until after the response has been received.

5.4.6 CHF-controlled quota management

CHF can instruct NF consumer (CTF) to suspend quota management for a given Rating Group and then subsequently the CHF can instruct the NF consumer (CTF) to resume quota management for the given Rating Group with suspended quota management within the charging session.

Upon receiving Charging Data Request [Initial/Update] with usage reporting for a set of rating groups, the CHF may suspend quota management for particular rating groups, by including in Charging Data Response messages for these particular rating groups:

– explicit setting of without quota management or

– granted quotas with appropriate content to ensure the service to continue without further quota management related updates.

CHF may instruct NF consumer (CTF) to resume quota management for a given rating group for which quota management was previously suspended:

– by using Re-authorization procedure or

– by granting quotas in the response to any Charging Data Request [Update] generated in situation quota management triggers are not used, by other existing active triggers of the NF consumer (CTF).

5.4.7 Charging identifier

The charging identifier is assigned by the NF consumer, making it possible to correlate the charging information from different events or sessions. The assignment is NF consumer dependent. The charging identifier may also be used for duplicate detection see clause 5.5.2.

5.5 Error handling

5.5.1 Failure handling

5.5.1.1 CTF detected failure

The failure handling determines what to do if the sending of charging data request to the CHF without response in a period of time (request times out).

In the case of the NF consumer (CTF) towards CHF request times out, NF consumer (CTF) uses application level failure handling (Terminate, Continue, Retry_and_terminate). Failure handling may be received from the CHF previously or may be locally configured. The value received from the CHF in the charging data response will always override any already existing value. Failover handling indication informs NF Consumer whether alternative CHF is supported.

In case there is an application level error response from the CHF, NF consumer (CTF) action will depend on the type of Application Error.

For protocol level errors, refer to applicable protocol failure handling mechanisms as described in 32.291 [58].

5.5.1.2 CHF detected failure

The CHF closes a CDR and all the reserved resources are freed for the charging session when it detects that expected charging data request for a particular session have not been received for a period of time. The charging session may be kept or released based on local configuration.

A Charging Data Request [Initial] received by a CHF, which can be associated to an existing charging session (i.e. , resource in CHF), should be handled as a valid request, with Charging Data Response including the charging session id (i.e. resource id). If there are errors during the handling, corresponding error code is returned.

A Charging Data Request [Update] received by a CHF, which cannot be associated to any existing charging session (i.e. , resource in CHF), should be handled as a valid request with the associated resource creation, quota usage handling and optional CDR creation. If there are errors during the handling, corresponding error code is returned.

A Charging Data Request [Termination] received by a CHF, which cannot be associated to any existing charging session (i.e. , resource in CHF), should be handled as a valid request with associated new resource creation and release, and optional corresponding CDR creation and closure. If there are errors during the handling, corresponding error code is returned.

The Invocation Sequence Number in Charging Data Request [Initial] with value different from 0 or 1 is faulty and shall be rejected by CHF.

5.5.2 Retry handling

In case a NF consumer (CTF) does not receive a Charging Data Response, it may retransmit the Charging Data Request message. The number of retries and delay between retries shall be locally configured in the NF consumer (CTF).

If the retried charging data request [Initial] is received by the same CHF, the uniqueness checking may be based on the Charging Identifier included in the charging data request. CHF shall respond to the retried charging data request [Initial] with the original charging session identifier.

If the retried request is charging data request [Update] or charging data request [Termination], the uniqueness checking may based on the inspection of the Charging Session Identifier and Invocation Sequence Number pair.

If retried message shall have the same Invocation Sequence Number as the original of the retried message i.e. the Invocation Sequence Number shall not be incremented when the message is retried. The NF consumer (CTF) may send the retried message to an alternative CHF if the Session Failover indication is received from the CHF. The alternative CHF can be built as defined in clause 5.23.1 of 3GPP TS 23.501 [201].

In the case of a notification request time out the CHF may retry the message. The number of retries and delay between retries shall be locally configured in the CHF.

5.5.3 Response code handling

The Charging Data Response includes a response code (i.e. Invocation Result Code in Invocation Result) which may indicate an error. The response codes supported by Nchf_ConvergedCharging service operations are specified 3GPP TS 32.291 [58].

A NF Consumer (CTF) receiving a Charging Data Response [Initial] with a response code indicating the Charging Data Request [Initial] was unsuccessfully processed, shall perform the error handling applicable to the response code and may send a Charging Data Request [Termination] to the CHF.

A NF Consumer (CTF) receiving a Charging Data Response [Termination] with a response code indicating the Charging Data Request [Termination] was unsuccessfully processed, shall perform the error handling applicable to the response code.

A NF Consumer (CTF) receiving a Charging Data Response [Update] with a response code indicating the Charging Data Request [Update] was unsuccessfully processed, shall perform the error handling applicable to the response code and may send a Charging Data Request [Termination] to the CHF.

The Charging Data Response may also include multiple "Multiple Unit Information" Information Elements, each one indicated with a Result code (i.e. applicable at Rating group level). The Result code values supported by Nchf_ConvergedCharging service operations are specified 3GPP TS 32.291 [58]. Any Invocation Result Code value different than success takes precedence over the set of "Multiple Unit Information" Result Codes.