4 Nchf_SpendingLimitControl Service

29.5943GPP5G SystemSpending Limit Control ServiceStage 3TS

4.1 Service Description

4.1.1 Overview

The Nchf_SpendingLimitControl service, as defined in 3GPP TS23.502 [3] and 3GPP TS23.503 [6], is provided by the Charging Function (CHF).

The Nchf_SpendingLimitControl service enables the NF service consumer (e.g. PCF) to retrieve policy counter status information and spending limit reporting per UE from the CHF.

If the spending limit reporting is no more required, the Nchf_SpendingLimitControl service enables the NF service consumer to unsubscribe from the reporting.

Nchf_SpendingLimitControl Service applies to the cases where the PCF interacts with the CHF in the non-roaming scenario, and the H-PCF interacts with the H-CHF in the home-routed scenario.

4.1.2 Service Architecture

The Nchf_SpendingLimitControl service is provided by the CHF and consumed by the NF service consumer (e.g. PCF), as shown in figure 4.1.2-1 for the SBI representation model and in figure 4.1.2-2 for the reference point representation model.

Figure 4.1.2-1: Nchf_SpendingLimitControl service architecture, SBI representation

Figure 4.1.2-2: Nchf_SpendingLimitControl service architecture, reference point representation

4.1.3 Network Functions

4.1.3.1 Charging Function (CHF)

The Charging Function (CHF) is part of the Converged Charging System (CCS). The CHF provides the Nchf_SpendingLimitControl service and is specified in 3GPP TS 32.240 [7].

4.1.3.2 NF Service Consumers

The PCF is the known NF service consumer, as defined in 3GPP TS 23.502 [3]. The NF service consumer accesses policy counter status information relating to the subscriber spending from the CHF and uses the status of each relevant policy counter as input to its policy decision as required by the decision logic.

4.2 Service Operations

4.2.1 Introduction

The service operations defined for the Nchf_SpendingLimitControl service are shown in table 4.2.1-1.

Table 4.2.1-1: Nchf_SpendingLimitControl Service Operations

Service operation name

Description

Initiated by

Nchf_SpendingLimitControl_Subscribe

This service operation is used by NF service consumers to subscribe to notification of changes in the status of the policy counters available and retrieval of the status of the policy counters for which subscription is accepted.

NF service consumer (e.g. PCF)

Nchf_SpendingLimitControl_Unsubscribe

This service operation is used by NF service consumers to unsubscribe from notification of changes in the status of all policy counters.

NF service consumer (e.g. PCF)

Nchf_SpendingLimitControl_Notify

This service operation is used by the CHF to notify the NF service consumers about the change of the status of the subscribed policy counters. Alternatively, it can be used by the CHF to notify that the status for one or multiple subscribed policy counter will change in the future, indicating the time when this change shall be applied. Alternatively, it is also used to notify the NF service consumer of the removal of a subscriber from the CHF system for the purpose that the NF service consumer can terminate the subscriptions of all policy counters of the subscriber.

CHF

4.2.2 Nchf_SpendingLimitControl_Subscribe service operation

4.2.2.1 General

The Nchf_SpendingLimitControl_Subscribe service operation is used by the NF service consumer to subscribe to notification of changes in the status of the policy counters available and to retrieve the status of the policy counters for which the subscription is accepted. The following procedures are related to the subscribe service operation:

– initial spending limit retrieval; and

– intermediate spending limit report retrieval.

4.2.2.2 Initial spending limit retrieval

Figure 4.2.2.2-1 shows the scenario where the NF service consumer sends a request to the CHF to retrieve the status of policy counters available at the CHF and to subscribe to spending limit reporting (see also 3GPP TS 23.502 [3], figure 4.16.8.2.1).

Figure 4.2.2.2-1: NF service consumer subscribes to retrieve policy counter status and spending limit reporting

The NF service consumer shall send an HTTP POST request to the resource "{apiRoot}/nchf-spendinglimitcontrol/v1/subscriptions" representing the "Spending Limit Retrieval Subscriptions", as shown in figure 4.2.2.2-1, step 1, to create a subscription for retrieval of the policy counter status and spending limit reporting.

The "SpendingLimitContext" data structure provided in the request body shall include:

– the Subscription Permanent Identifier (SUPI) encoded in the "supi" attribute;

– the notification correlation target address encoded in the "notifUri" attribute; and

– If the feature "NotificationCorrelation" is supported, a Notification Correlation Identifier assigned by the NF service consumer for the requested notifications encoded in the "notifId" attribute, if the "notifUri" does not encode within the provided URI the notification correlation Id.

NOTE: NF service consumer (e.g. PCF) ensures the combination of notifUri and notifId is unique per subscription in the whole network, including multiple network slices scenario.

The "SpendingLimitContext" data structure provided in the request body may include:

– the General Public Subscription Identifier (GPSI) encoded in the "gpsi" attribute;

– Event Filter information "list of policy counter identifier(s)" encoded in the "policyCounterIds" attribute. The "policyCounterIds" attribute shall contain the list of policy counter identifiers to be subscribed to. If the "policyCounterIds" attribute is omitted, the subscription is to all available policy counters; and

– when the feature "SubscriptionExpirationTimeControl" is supported by the NF service consumer, the NF service consumer may include an expiry time encoded in the "expiry" attribute, representing the time up to which the subscription is desired to be kept active. When the "expiry" attribute is omitted in the request, it represents the NF service consumer does not have any time constraint in the duration of the subscription.

If the CHF cannot successfully fulfil the received HTTP POST request due to an internal CHF error or due to the error in the HTTP POST request, the CHF shall send the HTTP error response as specified in clause 5.7.

If the subscriber specified in the request is unknown to the CHF, the CHF shall indicate in an HTTP "400 Bad Request" response the cause for the rejection with the "cause" attribute set to "USER_UNKNOWN".

If the CHF has no available policy counters specified for the subscriber, the CHF shall indicate in an HTTP "400 Bad Request" response the cause for the rejection with the "cause" attribute set to "NO_AVAILABLE_POLICY_COUNTERS ".

If one or more policy counters specified in the request in the "policyCounterIds" attribute are unknown to the CHF, and the CHF is configured to reject request, the CHF shall indicate in an HTTP "400 Bad Request" response the cause for the rejection with the "cause" attribute set to "UNKNOWN_POLICY_COUNTERS" and the unknown policy counter identifiers within the "invalidParams" attribute.

Otherwise, upon the reception of an HTTP POST request the CHF shall:

– create a new subscription resource, which contains the list of the policy counters included in the "policyCounterIds" attribute, or if the "policyCounterIds" attribute is omitted, all the policy counters of the subscriber;

– assign a subscriptionId; and

– store the subscription resource.

After the CHF created an "Individual Spending Limit Retrieval Subscription" resource, the CHF shall respond with "201 Created" response with a Location header field containing the URI of the created subscription resource and the message body containing a representation of the created subscription, as shown in figure 4.2.2.2-1, step 2.

The SpendingLimitStatus data structure provided in the response body shall include the status of the requested subscribed policy counters in the "statusInfos" map, where every PolicyCounterInfo entry shall contain:

– the policy counter identifier in the "policyCounterId" attribute; and

– the policy counter status in the "currentStatus" attribute.

When a requested policy counter identifier is known by the CHF, but it is not applicable to the subscriber (e.g. not provisioned), the CHF may include it in the "statusInfos" map, and set the "currentStatus" attribute to an operator configured policy counter status to indicate this to the NF service consumer.

When one or more policy counters specified in the request in the "policyCounterIds" attribute are unknown to the CHF, and the CHF is configured to accept the request, the CHF may include the unknown policy counters in the "statusInfos" map, and set the "currentStatus" attribute to an operator configured policy counter status to indicate this to the NF service consumer.

A PolicyCounterInfo data structure may include the list of the pending policy counter statuses and their activation times within the attribute "penPolCounterStatuses".

When the feature "SubscriptionExpirationTimeControl" is supported, the CHF may include the "expiry" attribute, representing the time up to which the subscription shall be kept active. If an expiry time was included in the subscription request, then the expiry time shall be returned in the response, and the value shall be less than or equal to the requested value. When the "expiry" attribute is omitted in the request and in the response, it represents neither the CHF or the NF service consumer have time constrains in the duration of the subscription and shall be kept active till the explicit subscription termination as described in clause 4.2.3.2 and clause 4.2.4.3.

NOTE 1: If the NF Service Consumer does not include a expiry time in the request, the CHF can include a expiry time in the response that represents the time after which the subscription becomes invalid.

NOTE 2: Once the subscription expires, if the NF service consumer wants to keep receiving notifications, it needs to create a new subscription in the CHF, as specified in this clause.

4.2.2.3 Intermediate spending limit report retrieval

Figure 4.2.2.3-1 shows the scenario where the NF service consumer sends a request to the CHF to modify the existing subscription to the retrieval of spending limit reports (see also 3GPP TS 23.502 [3], figure 4.16.8.3.1). The NF service consumer can add or remove policy counters to retrieve the status of the counters.

Figure 4.2.2.3-1: NF service consumer modifies the subscription to retrieve policy counter status and spending limit reporting

The NF service consumer shall send an HTTP PUT request to the resource "{apiRoot}/nchf-spendinglimitcontrol/v1/subscriptions/{subscriptionId}" representing an existing "Individual Spending Limit Subscription" resource, as shown in figure 4.2.2.3-1, step 1, to modify the subscription for retrieval of the policy counter status and spending limit reporting.

The "SpendingLimitContext" data structure provided in the request body:

– shall include the Subscription Permanent Identifier (SUPI) encoded in the "supi" attribute;

– shall include the notification correlation target address encoded in the "notifUri" attribute;

– if the feature "NotificationCorrelation" is supported, a Notification Correlation Identifier assigned by the NF service consumer for the requested notifications encoded in the "notifId" attribute, if the "notifUri" does not encode within the provided URI the notification correlation Id.

NOTE 1: If the notification correlation target address is not changed the previously provided notification correlation target address is included in the "notifUri" attribute. If the Notification Correlation Id is not changed the previously provided Notification Correlation Id is included in the "notifId" attribute.

– if the General Public Subscription Identifier (GPSI) was provided within the initial spending limit retrieval procedure, described in clause 4.2.2.2, shall include the GPSI encoded in the "gpsi" attribute; and

– may include Event Filter information as a "list of policy counter identifier(s)" encoded in the "policyCounterIds" attribute. The "policyCounterIds" attribute shall contain the updated list of policy counter identifiers to be subscribed to. If the "policyCounterIds" attribute is omitted, the subscription is updated to all available policy counters; and

– when the feature "SubscriptionExpirationTimeControl" is supported, may include an updated expiry time encoded in the "expiry" attribute to update the duration of the subscription, representing the updated time up to which the subscription is desired to be kept active. When the "expiry" attribute is omitted in the request, it represents the NF service consumer update does not have any time constraint from this moment on in the duration of the subscription.

NOTE 2: The "notifUri" attribute within the SpendingLimitContext data structure can be modified to request that subsequent notifications are sent to a new NF service consumer.

When the "policyCounterIds" attribute is present in the subscription request, this list of policy counters overrides a previously provisioned list.

After the CHF modified an "Individual Spending Limit Retrieval Subscription" resource, the CHF shall respond with "200 OK" response with the message body containing a representation of the modified subscription, as shown in figure 4.2.2.3-1, step 2.

The SpendingLimitStatus data structure provided in the response body, when the feature "SubscriptionExpirationTimeControl" is not supported, shall include the status of the requested subscribed policy counters in the "statusInfos" map, where every PolicyCounterInfo entry shall contain:

– the policy counter identifier in the "policyCounterId" attribute; and

– the policy counter status in the "currentStatus" attribute.

When a requested policy counter identifier is known by the CHF, but it is not applicable to the subscriber (e.g. not provisioned), the CHF may include it in the "statusInfos" map, and set the "currentStatus" attribute to an operator configured policy counter status to indicate this to the NF service consumer.

When one or more policy counters specified in the request in the "policyCounterIds" attribute are unknown to the CHF, and the CHF is configured to accept the request, the CHF may include the unknown policy counters in the "statusInfos" map, and set the "currentStatus" attribute to an operator configured policy counter status to indicate this to the NF service consumer.

A PolicyCounterInfo data structure may include the list of the pending policy counter statuses and their activation times within the attribute "penPolCounterStatuses".

When the feature "SubscriptionExpirationTimeControl" is supported, the CHF may include the "expiry" attribute, representing the time up to which the subscription shall be kept active. If an expiry time was included in the subscription update request, then the expiry time shall be returned in the response, and the value returned should be less than or equal to the value in the request. When the "expiry" attribute is omitted in the request and in the response, it represents that the subscription shall be considered valid without an expiry time.

NOTE 3: When the NF service consumer does not include an expiry time in the request, the CHF can include an expiry time in the response that represents an update of the previously provided duration of the subscription.

NOTE 4: Once the subscription expires, if the NF service consumer wants to keep receiving notifications, it needs to create a new subscription in the CHF, as specified in clause 4.2.2.2.

If errors occur when processing the HTTP PUT request, the CHF shall send an HTTP error response as specified in clause 5.7.

If the feature "ES3XX" is supported, and the CHF determines the received HTTP PUT request needs to be redirected, the CHF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [4].

If the CHF has no available policy counters specified for the subscriber, the CHF shall indicate in an HTTP "400 Bad Request" response the cause for the rejection with the "cause" attribute set to "NO_AVAILABLE_POLICY_COUNTERS ".

If one or more policy counters specified in the PUT request in the "policyCounterIds" attribute are unknown to the CHF, and the CHF is configured to reject request, the CHF shall indicate in an HTTP "400 Bad Request" response the cause for the rejection with the "cause" attribute set to "UNKNOWN_POLICY_COUNTERS" and the unknown policy counter identifiers within the "invalidParams" attribute. The PUT request shall not take effect, and the CHF shall maintain the Individual Spending Limit Retrieval resource.

NOTE 5: In order to avoid misbehaviors due to the policy counters status maintained in the CHF and the NF service consumer, the NF service consumer can terminate the subscription invoking the Nchf_SpendingLimitControl_Unsubscribe service operation in clause 4.2.3.2.

NOTE 6: The NF service consumer can terminate the subscription invoking the Nchf_SpendingLimitControl_Unsubscribe service operation in clause 4.2.3.2, or maintain subscription assuming that further available policy counters will be notified.

4.2.3 Nchf_SpendingLimitControl_Unsubscribe service operation

4.2.3.1 General

The Nchf_SpendingLimitControl_Unsubscribe service operation is used by the NF service consumer to cancel the subscription of status changes for all the policy counters available at the CHF. That means the complete cancellation of the spending limit reporting procedure.

4.2.3.2 Unsubscribe from spending limit reporting

Figure 4.2.3.2-1 shows the scenario where the NF service consumer sends a request to the CHF to unsubscribe from spending limit reporting (see also 3GPP TS 23.502 [3] figure 4.16.8.4.1).

Figure 4.2.3.2-1: NF service consumer unsubscribes from spending limit reporting

The NF service consumer shall invoke the Nchf_SpendingLimitControl_Unsubscribe service operation to unsubscribe from the spending limit reporting (status change for all policy counters available is no more required). The NF service consumer shall send an HTTP DELETE request to the resource "{apiRoot}/nchf-spendinglimitcontrol/v1/subscriptions/{subscriptionId}", whereby the "{subscriptionId}" is the identification of the existing subscription to be deleted. Upon the reception of an HTTP DELETE request the CHF removes the corresponding subscription.

If the HTTP DELETE request is accepted by the CHF, it shall respond with "204 No Content" as shown in figure 4.2.3.2-1, step 2.

If the HTTP DELETE request is not accepted by the CHF (e.g. the HTTP DELETE request is for a non-existent subscription), it shall indicate the appropriate cause for the rejection in the HTTP response code or, if the feature "ES3XX" is supported, an HTTP redirect response to the NF service consumer.

4.2.4 Nchf_SpendingLimitControl_Notify service operation

4.2.4.1 General

The Nchf_SpendingLimitControl_Notify service operation is used by the CHF:

– to notify the change of the status of the subscribed policy counters available at the CHF for that subscriber; and/or

– to provide one or more pending statuses for a subscribed policy counter together with the time they shall be applied; and/or

– to request the termination of the subscription of status changes for all policy counters for a subscriber (e.g. the subscriber is removed from the CHF system).

4.2.4.2 Spending limit report

Figure 4.2.4.2-1 shows the scenario where the CHF sends a notification to the NF service consumer, when it detects that the status of a policy counter(s) has changed and the NF service consumer has subscribed to notifications of changes in the status of this policy counter(s). The CHF can also notify the NF service consumer that the status for one or multiple subscribed policy counter will change and indicate this by providing the time when this change shall be applied (see also 3GPP TS 23.502 [3], figure 4.16.8.5.1).

Figure 4.2.4.2-1: Spending limit reporting

The CHF shall send an HTTP POST request to the resource notification target address (notifUri) of the NF service consumer received in the subscription creation or modification, and shall append the "notify" segment path at the end of the URI, to indicate the NF service consumer the notification of a policy counter status change.

The SpendingLimitStatus data structure provided in the request body:

– shall include the Subscriber Identity in the "supi" attribute;

– shall include, if the feature "NotificationCorrelation" is supported, the notification correlation ID in the "notifId" attribute if received in the SpendingLimitContext data structure provided in the creation or update of the subscription;

– shall include, when the feature "SubscriptionExpirationTimeControl" is not supported, Policy counters status in the "statusInfos" map, where every PolicyCounterInfo entry shall include:

a. the "policyCounterId" attribute with the policy counter identifier; and

b. the "currentStatus" attribute with the new policy counter status when the notification is triggered by a change in the policy counter status, or the current policy counter status when the notification is triggered by a change in the pending policy counter status(es); and

– may include, when the feature "SubscriptionExpirationTimeControl" is supported, the Policy counters status in the "statusInfos" map if at this time there is change of policy counter status and/or the update of the expiry time in the "expiry".

NOTE 1: When the feature "SubscriptionExpirationTimeControl" is supported, and the CHF includes the update of the expiry time, if at this time there is no change of policy counter status, the CHF does not include the "statusInfos" attribute.

When a policy counter identifier is no longer applicable to the subscriber (e.g. becomes not provisioned), but still exists in the Individual Spending Control Retrieval resource, the CHF may include it in the "statusInfos" map, and set the "currentStatus" attribute to an operator configured policy counter status to indicate this to the NF service consumer.

A PolicyCounterInfo data structure may include the list of pending policy counter statuses and their activation times within the attribute "penPolCounterStatuses.

When the feature "SubscriptionExpirationTimeControl" is supported, the CHF may include the "expiry" attribute, representing an update in the time up to which the subscription shall be kept active. When the "expiry" attribute is omitted, it represents that the previously agreed duration of the subscription remains valid.

NOTE 2: Once the subscription expires, if the NF Service Consumer wants to keep receiving notifications, it needs to create a new subscription in the CHF, as specified in clause 4.2.2.2.

The CHF shall not send the policy counter status for the same policy counter until it received the response of the previous status report of the policy counter.

If the HTTP POST notification request message is accepted by the NF service consumer, it shall acknowledge the receipt of the event notification with a "204 No Content" response, as shown in figure 4.2.4.2-1, step 2.

If errors occur when processing the HTTP POST request, the NF service consumer shall send an HTTP error response as specified in clause 5.7.

If the feature "ES3XX" is supported, and the NF service consumer determines the received HTTP POST request needs to be redirected, the NF service consumer shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [4].

If the NF service consumer receives an HTTP POST notification request message for an intermediate spending limit report transaction from the CHF in which no pending policy counter statuses and their activation times are included for a policy counter, i.e., the "penPolCounterStatuses" attribute is not included, the NF service consumer shall cancel all previously provided pending policy counter statuses and their activation times for this policy counter. If the NF service consumer receives an HTTP POST notification request message for an intermediate spending limit report transaction from the CHF containing pending policy counter statuses and their activation times for a previously provided policy counter, the NF service consumer shall replace the existing pending policy counter statuses and their activation times if any.

If the NF service consumer receives an HTTP POST request for spending limit report initiated by the CHF while it has an ongoing intermediate spending limit report retrieval transaction with the CHF, the NF service consumer shall update the policy counter information based on the HTTP POST request for spending limit report. When the corresponding response for the ongoing intermediate spending limit report retrieval transaction is eventually received, the NF service consumer shall only update policy counter information for counters that were not provided in the previously received HTTP POST request for spending limit report.

4.2.4.3 Subscription termination request by CHF

Figure 4.2.4.3-1 shows the scenario where the CHF sends a notification to the NF service consumer, when it requests the termination of the subscription of status changes for all policy counters for a subscriber.

Figure 4.2.4.3-1: Subscription termination request by CHF

The CHF shall send an HTTP POST request to the resource notification target address (notifUri) of the NF service consumer received in the subscription creation or modification and shall append the "terminate" segment path at the end of the URI, to indicate the subscription termination and the removal of the Individual Spending Limit Retrieval Subscription resource to the NF service consumer.

The SubscriptionTerminationInfo data structure provided in the request body shall include the subscriber identification encoded in the "supi" attribute, if the feature "NotificationCorrelation" is supported, the Notification Correlation Id in the "notifId" attribute if received and may include subscription termination information in the "termCause" attribute.

When the termination request is because the subscriber identified by the SUPI has been removed from the CHF, the CHF shall set the "termCause" attribute to "REMOVED_SUBSCRIBER".

If the HTTP POST notification request message is accepted by the NF service consumer, it shall remove the subscription to notifications of all policy counters for a subscriber and shall acknowledge the receipt of the event notification with a "204 No Content" response, as shown in figure 4.2.4.3-1, step 2.

If errors occur when processing the HTTP POST request, the NF service consumer shall send an HTTP error response as specified in clause 5.7.

If the feature "ES3XX" is supported, and the NF service consumer determines the received HTTP POST request needs to be redirected, the NF service consumer shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [4].