Patent Description:
Usage monitoring functionality allows a network operator to control the data usage of the subscriber. This can be done at service level or per PDU session level. For example, a network operator may specify that a certain subscriber may not download more than <NUM> Gigabytes of Netflix data per month.

The usage monitoring functionality is controlled by a network node that implements a policy function (e.g., the <NUM> Policy and Charging Rules Function (PCRF) or the <NUM> Policy Control Function (PCF)). A monitoring key is assigned by the policy function (e.g., PCRF/PCF) in order to allow a traffic handling network function (e.g., the <NUM> PGW/UP or <NUM> SMF/UPF) to monitor the traffic associated to that monitoring key.

The monitoring key is assigned by the policy function and is provided as part of the policy rules (e.g., PCC rule(s)) when monitoring applies at service level or as part of the session information when the monitoring applies to a session (e.g., IP-CAN/PDU session). All the service data flows or applications that share the same monitoring key will have a common allowed usage for a subscriber's terminal device (also known as user equipment (UE)) on an APN (<NUM>)/DNN (<NUM>) basis.

Usage monitoring information is stored in the SPR (<NUM>) or UDR (<NUM> & <NUM>).

The interface towards the data base is not specified for Non-<NUM> scenarios. In <NUM>, 3GPP TS <NUM> (stage <NUM>) and TS <NUM> (stage <NUM>) specify the interface between the PCF and UDR. <CIT> discloses a method according to the preamble portion of claim <NUM>.

Certain challenges currently exist. 3GPP TS <NUM> V15. <NUM> ("TS <NUM>") specifies the interface between the PCF and the Unified Data Repository (UDR). According to TS <NUM>, a specific resource is defined to control the usage monitoring information. The usage monitoring information is stored according to this structure: {apiRoot}/nudr-dr/v1/policy-data {ueId} /sm-data/ {usageMonId}.

The PCF can create a usage monitoring resource in order to store the remaining usage related to a UsageMonId. This resource can also be removed once the corresponding limit no longer exists. The PCF can get and modify usage monitoring information associated with a UE id and usageMonId at any moment during the lifetime of a PDU session:.

It is not specified how the PCF derives the usageMonId or how the usageMonId relates with the information in the usage limits (UsageMonDataLimit data type) or in the monitoring data (UsageMonData).

The resource definition for the UsageMonitoringInformation resource does not clearly define which identifier to use in the "usageMonId" variable field.

It may be assumed that the "usageMonId" variable field corresponds to the monitoring key that the PCF uses to monitor the traffic towards the SMF. But, if the monitoring key is used in the "usageMonId", then it is necessary to restrict the scope of the monitoring key as currently specified (i.e., per UE and DNN). The following possible new scopes of the monitoring key values could be considered.

Each of the above possibilities restrict the way the monitoring key is used today that decouples its usage in the context of usage monitoring in the SMF/UPF from the way the accumulation is performed in the user data base.

Accordingly, this disclosure proposes to use an identifier in the "usageMonId" resource identifier (e.g., URI) variable that identifies a certain usage limit. This identifier may be referred to as the "Accumulator/Limit Identifier" or ("limitId" for short). A UsageMonitoringInformation individual resource represents accumulated usage information corresponding to a certain limit identified by a limit identifier. Consequently, there is no restriction in the definition of the monitoring key values. This solution also requires that the limitId be included in the UsageMonDataLimit and UsageMonData data types. An advantage of the proposed solution is that it provides the highest degree of flexibility respecting the current scope of the monitoring key. The proposed solution also allows a decoupling of the use of the monitoring key from the way the accumulation is done in the UDR, and further allows flexible models in the way the accumulation is done. There is no restriction in the definition of the monitoring key, allowing different business models where the accumulation can be done per different combinations of DNN and S-NSSAI. A further advantage is that there is no impact in the way usage monitoring has been specified.

Accordingly, in one aspect a method is provided wherein the method includes a policy function (e.g., PCF) transmitting to a depository function (e.g., UDR) a request for information. The method also includes the policy function receiving a response, wherein the response comprises: a usageMonDataLimit instance comprising a limit identifier, wherein the limit identifier identifies a usage monitoring control instance; and a usageMonData instance corresponding to the usageMonDataLimit instance, wherein the usageMonData instance also comprises the limit identifier.

In some embodiments, the method also includes, prior to transmitting the request, the policy function receiving a request from a management function; and, in response to the request, the policy function determining whether or not the policy function needs to fetch the information from the depository function.

In some embodiments the method also includes the policy function transmitting to the depository function a request requesting the depository function to provide a notification to the policy function when changes occur to the UsageMonData instance associated with the UsageMonDataLimit instance.

In some embodiments the method also includes the policy function transmitting to the depository function an update request. In some embodiments, the update request is an HTTP PATCH request comprising a UsageMonData instance comprising the limit identifier, or the update request is an HTTP PUT request comprising a resource identifier (e.g., a URI) comprising the limit identifier.

In some embodiments the method also includes the policy function transmitting to the depository function an unsubscribe request, wherein transmitting the unsubscribe request comprises transmitting an HTTP PUT request comprising a body comprising a resource identifier comprising the limit identifier.

In some embodiments, the usageMonDataLimit instance further comprises at least one of: a usage monitoring level instance indicating whether the usageMonDataLimit
instance applies at a PDU session level or a service level, start date information indicating a start date and time, end date information indicating an end date and time, a usage limit threshold value indicating a maximum allowed traffic volume, or a reset period for use in indicating a time at which an allowed usage needs to be reset.

In some embodiments, the usageMonDataLimit instance further comprises a data scope indicating an S-NSSAI and DNN combination to which the usageMonDataLimit instance applies.

In some embodiments, the usageMonData instance further comprises at least one of: a usage monitoring level, umLevel, instance indicating whether the usageMonData instance applies at PDU session level or at service level, or an allowed usage value, wherein the allowed usage value indicates a remaining allowed traffic volume, and/or the allowed usage value indicates a remaining length of time.

In some embodiments, the usageMonData instance further comprises information indicating a time at which to reset an allowed usage to the usage limit threshold value.

In another aspect a method is provided wherein the method includes a depository function (e.g., UDR) receiving a request for information from a policy function (e.g., PCF). The method also includes the depository function transmitting a response in response to the request, wherein the response comprises: a usageMonDataLimit instance comprising a limit identifier, wherein the limit identifier identifies a usage monitoring control instance; and a usageMonData instance corresponding to the usageMonDataLimit instance, wherein the usageMonData instance also comprises the limit identifier.

In some embodiments the method also includes the depository function receiving an update request from the policy function. In some embodiments, the update request is an HTTP PATCH request comprising a UsageMonData instance comprising the limit identifier, or the update request is an HTTP PUT request comprising a resource identifier comprising the limit identifier.

In some embodiments the method also includes the depository function receiving an unsubscribe request from the policy function. In some embodiments, the unsubscribe request is an HTTP PUT request comprising a body comprising a resource identifier comprising the limit identifier.

In some embodiments, the usageMonDataLimit instance further comprises at least one of: a usage monitoring level instance indicating whether the usageMonDataLimit instance applies at a PDU session level or at a service level, start date information indicating a start date and time, end date information indicating an end date and time, a usage limit threshold value indicating a maximum allowed traffic volume, or a reset period for use in indicating a time at which an allowed usage needs to be reset.

In some embodiments, the usageMonData instance further comprises at least one of: a usage monitoring level, umLevel, instance indicating whether the usageMonData instance applies at a PDU session level or at a service level, or an allowed usage value, wherein the allowed usage value indicates a remaining allowed traffic volume, and/or the allowed usage value indicates a remaining length of time.

In another aspect there is provided a computer program comprising instructions which when executed by processing circuitry of an apparatus causes the apparatus to perform the methods described herein. In another aspect, there is provided a carrier containing the computer program described in the previous paragraph, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.

In another aspect there is provided a policy function apparatus. The policy function apparatus is adapted to transmit to a depository function a request for information and receive a response to the request. The response includes a usageMonDataLimit instance comprising a limit identifier, wherein the limit identifier identifies a usage monitoring control instance, and a usageMonData instance corresponding to the usageMonDataLimit instance, wherein the usageMonData instance also comprises the limit identifier.

In another aspect there is provided a depository function apparatus. The depository function apparatus is adapted to receive a request for information from a policy
function and transmit a response in response to the request from the policy function. The response comprises: a usageMonDataLimit instance comprising a limit identifier, wherein the limit identifier identifies a usage monitoring control instance, and a usageMonData instance corresponding to the usageMonDataLimit instance, wherein the usageMonData instance also comprises the limit identifier.

As noted above, TS <NUM> specifies the interface between the PCF and the UDR. According to TS <NUM>, a specific resource is defined to control the usage monitoring information. The usage monitoring information is stored according to this structure: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}. The resource structure is shown in <FIG>.

The proposed solution requires changes to the current version of TS <NUM>. Section <NUM>. <NUM> of TS <NUM> defines various structured data types. One of the defined structured data types is the "UsageMonDataLimit" type, which is defined in table <NUM>. <NUM>-<NUM> of TS <NUM>. This table is shown below:.

The UsageMonDataLimit type may change over time to include other attributes. For example, the UsageMonDataLimit type may also include an attribute having the name "scopes. " A "scopes" attribute is of type UsageMonDataScope and comprise information identifying an S-NSSAI and DNN combination to which the usageMonDataLimit instance applies.

This disclosure proposes modifying the definition such that the UsageMonDataLimit type includes an attribute named "limitId. " The limitId attribute has a data type of "string", is mandatory (M), and has a cardinality of <NUM>. The description for this new attribute is: "Identifies the limit. " That is, the limitId attribute identifies a usage monitoring control instance.

Another one of the defined structured data types is the "UsageMonData" type, which is currently defined in table <NUM>. <NUM>-<NUM> of TS <NUM>, which is shown below:.

This disclosure proposes replacing the "monKey" attribute with an attribute named "limitId. " The limitId attribute has a data type of "string", is mandatory (M), and has a cardinality of <NUM>. The description for this new attribute is: "Identifies the limit as defined in the 'limitId' attribute of the UsageMonDataLimit data type (see subclause <NUM>. <NUM> of TS <NUM>).

The UsageMonData type may change over time to include other attributes. For example, the UsageMonData type may also include an attribute having the name "resetTime. " A "resetTime" attribute is of type DateTime and comprise information indicating a time at which to reset an allowed usage back to the usageLimit of the corresponding UsageMonDataLimit.

Section <NUM>. <NUM> of TS <NUM> describes the "UsageMonitoringInformation" resource. As explained in section <NUM>. <NUM> of TS <NUM>, the UsageMonitoringInformation "resource represents an individual usage monitoring resource created in the UDR and associated with a ueId and a usageMonId.

Section <NUM>. <NUM> of TS <NUM> provides the "Resource Definition. " Specifically, the section provides that the resource identifier for the resource is: "{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}". Section <NUM>. <NUM> of TS <NUM> currently defines the variables apiRoot, ueId, and usageMonId as shown in the table below (which corresponds to Table <NUM>. <NUM>-<NUM> of TS <NUM>).

This disclosure further extends the definition of usageMonId, such that the usageMonId variable is not only a "unique identifier of the individual SM Policy usage monitoring resource," but also contains the identity of the corresponding limit as defined in the "limitId" attribute of the UsageMonDataLimit data type, as described above. This disclosure further proposes to change the technical specification such that no URI query parameters are supported by the GET method for the UsageMonitoringInformation resource.

<FIG> is a message flow diagram showing, for example, a PCF <NUM> communicating with a UDR <NUM>. UDR <NUM> is the subscriber repository where the PCF <NUM> stores and retrieves policy data for a user, a S-NSSAI, and a DNN. Details for the interactions with the UDR in the PCC flows have been agreed in C3-<NUM> (currently available at www. org/FTP/Meetings_3GPP_SYNC/CT3/Inbox/C3-<NUM>.

This procedure shown in <FIG> concerns both roaming and non-roaming scenarios. In the home routed roaming case, the PCF <NUM> acts as the H-PCF. In the LBO roaming case, the PCF <NUM> acts as the V-PCF, and the step <NUM> to <NUM> may be skipped.

Step <NUM>: The SMF <NUM> receives a PDU session establishment request from a user equipment (UE). That is, the SMF <NUM> receives a PDU session establishment request transmitted by the UE towards the SMF. The SMF <NUM> selects a PCF as described in subclause <NUM> of TS <NUM> and invokes the Npcf_SMPolicyControl_Create service operation by sending the HTTP POST request to the resource URI "{apiRoot}/npcf-smpolicycontrol/v1/sm-policies". The request operation provides the SUPI, the PDU session ID, PDU Session Type, DNN, and S-NSSAI, and may provide the GPSI, the Internal Group Identifier, the Access Type, the IPv4 address or the IPv6 network prefix (if available), the PEI if received in the SMF <NUM>, the User Location Information, the UE Time Zone, Serving Network, RAT type, charging information, the subscribed Session-AMBR and the subscribed default 5QI/ARP, if available. The request operation also includes a Notification URI to indicate to the PCF where to send a notification when the SM related policies are updated.

Step <NUM>: The PCF <NUM> determines whether it has subscription data for the SUPI and DNN. If the PCF <NUM> does not have the subscription data for the SUPI and DNN, the PCF <NUM> invokes the Nudr_DataRepository_Query service operation to the UDR <NUM> (e.g., the PCF <NUM> sends to the UDR <NUM> an HTTP GET request identifying the resource URI: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data, as specified in TS <NUM>.

Step <NUM>: The UDR <NUM> receives the GET request and then sends an HTTP "<NUM> OK" response to the PCF <NUM>. The response includes the resources under {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data, which contain the UsageMonDataLimit applicable instances with the limits definition, and the UsageMonData applicable instances, with the usage consumption information.

Note that UsageMonDataLimit instances are stored in the. /sm-data resource, and UsageMonData instances are stored in the /{usageMonId} resource, and both are retrieved with the GET request to the. /sm-data Resource URI
Each UsageMonDataLimit instance contains the "limitId" attribute identifying the name of the limit (e.g. "limitId" : "Facebook-limit") together with the defined usageLimit (e.g. "usageLimit" : "500MB") and other optional parameters.

Each UsageMonData instance contains the "limitId" attribute identifying the name of the limit (e.g. "limitId" : "Facebook-limit") together with the remaining usage in the "allowedUsage" attribute (e.g. "allowedUsage" : "200MB")
The UDR <NUM> provides the UsageMonData per existing {usageMonId}. The UsageMonData includes the limitId instead of the monitoringKey.

Step <NUM>: When the PCF <NUM> receives the response transmitted by the UDR <NUM>, the PCF <NUM> detects whether the response includes a UsageMonDataLimit instance for the UE. If the PCF <NUM> detects that there is a UsageMonDataLimit for the UE, the PCF <NUM> may request the UDR <NUM> to provide notifications to the PCF <NUM> when changes occur to the UsageMonData instance associated with the UsageMonDataLimit instance (i.e., the UsageMonData instance that contains the same limitId that is contained in and identifies the UsageMonDataLimit instance). The PCF <NUM> requests these notifications from the UDR <NUM> by invoking Nudr_DataRepository_Subscribe service operation (e.g., transmitting to the UDR <NUM> an HTTP message comprising the URI: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}", where the "usageMonId" is the "limitId" contained in the received UsageMonDataLimit instance. Note PCF <NUM> may also subscribe to receive notification of changes on the data represented in the sm-data resource.

Step <NUM>: The UDR <NUM> sends an HTTP "<NUM> Created" response to acknowledge the subscription from the PCF <NUM>.

Step <NUM>: If the PCF <NUM> determines that the policy decision depends on the status of the policy counters available at the CHF <NUM>, and such reporting is not established for the subscriber, the PCF <NUM> initiates an Initial Spending Limit Report Retrieval as defined in subclause <NUM>. <NUM> of 3GPP TS <NUM> V15. If policy counter status reporting is already established for the subscriber, and the PCF <NUM> determines that the status of additional policy counters are required, the PCF <NUM> initiates an Intermediate Spending Limit Report Retrieval as defined in subclause <NUM>. <NUM> of 3GPP TS <NUM> V15.

Step <NUM>: The PCF <NUM> makes the policy decision to determine the information provided in step <NUM>.

Step <NUM>: The PCF <NUM> sends an HTTP "<NUM> Created" response to the SMF <NUM> with the determined policies as described in subclause <NUM>. <NUM> of 3GPP TS <NUM> V15. After this step the PCF <NUM> can subscribe to SMF <NUM> events associated with the PDU Session.

<FIG> is another message flow diagram showing communications between various functions including the PCF <NUM> and the UDR <NUM>.

Step <NUM>: The SMF <NUM> invokes the Npcf_SMPolicyControl_Delete service operation by sending the HTTP POST request with " {apiRoot}/npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/delete" as the resource URI to request the PCF to delete the context of the SM related policy. The request operation may include usage monitoring information (if applicable) and access network information.

Step <NUM>: Upon receipt of Npcf_SMPolicyControl_Delete service operation, the PCF identifies the PCC Rules that require an AF <NUM> to be notified and removes PCC Rules for the PDU Session.

Step <NUM>: The SMF <NUM> removes all the PCC Rules which are applied to the PDU session.

Step <NUM>: The PCF <NUM> invokes the Npcf_PolicyAuthorization_Notify service operation by sending the HTTP POST request with " {notifUri}/notify" as the resource URI to the AF <NUM> to indicate that there are no transmission resources for the service if this is requested by the AF <NUM>.

Step <NUM>: The AF <NUM> sends an HTTP "<NUM> No Content" response to the PCF <NUM>.

Step <NUM>: The AF <NUM> invokes the Npcf_PolicyAuthorization_Delete service operation by sending the HTTP POST request to the resource URI " {apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId}/delete". The request may include the events to subscribe to.

Step <NUM>: The PCF <NUM> removes the AF application session context and sends an HTTP "<NUM> No Content" response to the AF. If the PCF <NUM> need to report usage data or the access network information, it sends an HTTP "<NUM> OK" response. If usage thresholds were provided by the AF earlier, and the PCF <NUM> has usage data that has not yet been reported to the AF, the PCF <NUM> informs the AF <NUM> about the resources that have been consumed by the user since the last report. If the SMF <NUM> in step <NUM> reports the access network information and if the AF <NUM> requested the PCF <NUM> to report access network information previously, the PCF <NUM> informs the AF <NUM> about the access network information. The PCF <NUM> also deletes the subscription to PCF <NUM> detected events for that AF application session.

Step 4a: The PCF <NUM> indicates the session abort to the AF <NUM> by sending a diameter ASR to the AF <NUM>.

Step 5a: The AF <NUM> responds by sending a diameter ASA to the PCF <NUM>.

Step 6a: The AF <NUM> sends a diameter STR to the PCF <NUM> to indicate that the session has been terminated.

Step 7a: The PCF <NUM> responds by sending a diameter STA to the AF <NUM>. Steps 4a, 5a, 6a, and 7a are for the "Rx" case, i.e., when the PCF <NUM> support the Rx interface with the AF <NUM>. Details of the Rx interface can be found in 3GPP TS <NUM> V15.

Step <NUM>: If this is the last PDU session for this subscriber the Final Spending Limit Report Request as defined in clause <NUM>. <NUM> of 3GPP TS <NUM> V15. <NUM> is sent. If any existing PDU sessions for this subscriber require policy counter status reporting, the Intermediate Spending Limit Report Request as defined in clause <NUM>. <NUM> of 3GPP TS <NUM> V15. <NUM> can be sent to alter the list of subscribed policy counters.

Step <NUM>: The PCF <NUM> removes PCC Rules for the terminated PDU Session and sends an HTTP "<NUM> No Content" response to the SMF <NUM>.

Step <NUM>: At SM Policy Association Termination, the PCF <NUM> updates the remaining usage in the UDR for the applicable limits. The PCF <NUM> can send a PATCH request to the. /sm-data resource URI including the updated values of the remaining usage in the "allowedUsage" attribute included in the corresponding "UsageMonData" instances, where each "UsageMonData" instance is identified by its "limitId" (e.g. "limitId" : "Facebook-limit" and "allowedUsage" : "125MB"). Alternatively, the PCF <NUM> can send a PUT request to the. /{usageMonId} resource URI per each "UsageMonData" instance the PCF <NUM> needs to update. The "usageMonId" value is the "limitId" value (e.g.. /facebook-limit resource URI for Facebook consumption, and. Inetflix-premium resource URI for Netflix premium consumption). UDR stores the remaining usage related to the limitId (instead of using the monitoring key).

Step <NUM>: The UDR <NUM> sends an HTTP "<NUM> No Content" response to the PCF <NUM>.

Step <NUM>: The PCF <NUM> may unsubscribe to receive changes related to the Resource ID. /{usageMonId} identified by the limitId. Note that the PCF <NUM> may also unsubscribe to receive notification of changes on the data represented in the sm-data resource. To terminate the subscription to changes in the usage monitoring data represented in the. /{usageMonId}, the PCF <NUM> may send a PUT request to the resource URI: {apiRoot}/nudr-dr/v1/policy-data/subs-to-notify. The body of this PUT request includes a PolicyDataSubscription data structure with an updated list of "monitoredResourceUris," which list would not include the before mentioned. /{usageMonId} resource URI. Alternatively, the PCF <NUM> may terminate the subscription to notification to any data change by sending a DELETE request to the {apiRoot}/nudr-dr/v1/policy-data/subs-to-notify resource URI.

Step <NUM>. The UDR <NUM> sends an HTTP "<NUM> No Content" response to the PCF <NUM>.

<FIG> is a flow chart illustrating a process <NUM> according to an embodiment. Process <NUM> may begin in step s402.

Step s402 comprises a policy function (e.g., PCF <NUM>) receiving a request <NUM> (see <FIG>) from a management function (e.g., SMF <NUM>), the request being related to a UE. That is, the management function transmitted the request <NUM> towards the policy function such that the policy function receives the request (directly or indirectly) from the management function.

Step s404 comprises the policy function determining whether or not it needs to fetch from a depository function (e.g., UDR <NUM>) information pertaining to the UE. If the policy function needs to fetch the information, process <NUM> proceeds to step <NUM>, otherwise it proceeds to step <NUM>.

Step s406 comprises the policy function transmitting to the depository function a request <NUM> for information. That is, for example, in embodiments in which the policy function is implemented in software, the software instructs the hardware on which it runs to transmit the request <NUM>.

Step s408 comprises the policy function receiving a response <NUM> to the request, wherein the response was transmitted by the depository function and the response comprises: a usageMonDataLimit instance comprising a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, wherein the usageMonData instance also comprises the limit identifier. When the policy function receives the response from the depository function (directly or indirectly), the policy function detects whether the response includes a UsageMonDataLimit instance for the UE. If the policy function detects that there is a UsageMonDataLimit for the UE, the policy function performs step s409.

Step s409 comprises the policy function transmitting to the depository function a request <NUM> to provide notifications when changes occur to the UsageMonData instance associated with the UsageMonDataLimit instance.

Step s410 comprises the policy function sending a response <NUM> to the management function.

Step s412 comprises the policy function receiving (directly or indirectly) from the management function a request <NUM> to delete the context of an SM related policy.

Step s414 comprises the policy function transmitting an update request <NUM> to the depository function (e.g., a HTTP PATCH or PUT as described above with respect to step <NUM> of <FIG>).

Step s416 comprises the policy function transmitting an unsubscribe request <NUM> to the depository function as described above with respect to step <NUM> of <FIG>.

<FIG> is a flow chart illustrating a process <NUM> according to an embodiment. Process <NUM> may begin in step s502.

Step s502 comprises a depository function (e.g., UDR <NUM>) receiving a request <NUM> for information from a policy function (e.g., PCF <NUM>).

Step s504 comprises the depository function transmitting a response <NUM> in response to the request <NUM>, wherein the response comprises: a usageMonDataLimit instance comprising a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, wherein the usageMonData instance also comprises the limit identifier.

Step s506 comprises the depository function receiving an update request <NUM> (e.g., a HTTP PATCH or PUT as described above with respect to step <NUM> of <FIG>) from the policy function.

Step s508 comprises the depository function receiving an unsubscribe request <NUM> from the policy function as described above with respect to step <NUM> of <FIG>.

<FIG> is a block diagram of an apparatus <NUM> for implementing a PCF <NUM> or a UDR <NUM>, according to some embodiments. For example, in embodiments where the PCF <NUM> and/or the UDR <NUM> consist of software (e.g., scripts and/or compiled code), apparatus <NUM> can execute the PCF/UDR software. Accordingly, apparatus <NUM> may be referred to as a policy function apparatus in embodiments in which apparatus <NUM> executes PCF software. Likewise, apparatus <NUM> may be referred to as a depository function apparatus in embodiments in which apparatus <NUM> executes UDR software. As shown in <FIG>, apparatus <NUM> may comprise: processing circuitry (PC) <NUM>, which may include one or more processors (P) <NUM> (e.g., one or more general purpose microprocessors and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed; a network interface <NUM> comprising a transmitter (Tx) <NUM> and a receiver (Rx) <NUM> for enabling apparatus <NUM> to transmit data to and receive data from other nodes connected to a network <NUM> (e.g., an Internet Protocol (IP) network) to which network interface <NUM> is connected; and a local storage unit (a. , "data storage system") <NUM>, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. In embodiments where PC <NUM> includes a programmable processor, a computer program product (CPP) <NUM> may be provided. CPP <NUM> includes a computer readable medium (CRM) <NUM> storing a computer program (CP) <NUM> comprising computer readable instructions (CRI) <NUM>. CRM <NUM> may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI <NUM> of computer program <NUM> is configured such that when executed by PC <NUM>, the CRI causes apparatus <NUM> to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, apparatus <NUM> may be configured to perform steps described herein without the need for code. That is, for example, PC <NUM> may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

The following illustrates changes to TS <NUM> that have been proposed.

This resource shall support the resource URI variables defined in the table below.

This method shall support the URI query parameters specified in the table below.

While various embodiments are described herein, it should be understood that they have been presented by way of example.

Claim 1:
A method (<NUM>), comprising:
a policy function (<NUM>) transmitting (s406) to a depository function (<NUM>) a request (<NUM>) for information; and
the policy function (<NUM>) receiving (s408) a response (<NUM>) to the request,
characterized in that the response (<NUM>) comprises:
a usageMonDataLimit instance comprising a limit identifier, wherein the limit identifier identifies a usage monitoring control instance; and
a usageMonData instance corresponding to the usageMonDataLimit instance, wherein the usageMonData instance also comprises the limit identifier.