JP2024150489A - Usage monitoring data control - Google Patents

Abstract

A method, program, method, policy device, and depository function device for managing usage monitoring data are provided. The method for managing usage monitoring data includes a policy function sending a request for information to a depository function (s406), and the policy function receiving a response to the request (s408), the response having a usageMonDataLimit instance having a limit identifier, and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having a limit identifier.

Description

[001] This disclosure relates to management of usage monitoring data.

[002] Usage monitoring allows network operators to control subscriber data usage. This can be done at the service level or at the per-PDU session level. For example, a network operator can specify that a given subscriber cannot download more than 5 gigabytes of Netflix data per month.

[003] The usage monitoring function is controlled by a network node implementing a policy function (e.g., a 4G Policy and Charging Rules Function (PCRF) or a 5G Policy Control Function (PCF)). A monitoring key is assigned by the policy function (e.g., the PCRF/PCF) to enable a traffic handling network function (e.g., a 4G PGW/UP or a 5G SMF/UPF) to monitor traffic relating to that monitoring key.

[004] Monitoring keys are assigned by the policy function. They are provided as part of the policy rules (e.g. PCC rules) if monitoring is applied at the service level, or as part of the session information if monitoring is applied to a session (e.g. IP-CAN/PDU session). All service data flows or applications sharing the same monitoring key will have a common usage allowance for the subscriber's terminal device (also called User Equipment (UE)) per APN (4G)/DNN (5G).

[005] Usage monitoring information is stored in the SPR (4G) or UDR (4G and 5G).

[006] For non-5G scenarios, the interface towards the database is not specified. For 5G, 3GPP TS 23.503 (Stage 2) and TS 29.519 (Stage 3) specify the interface between the PCF and the UDR.

[007] Currently, a problem exists. 3GPP TS 29.519 V15.1.0 (hereinafter referred to as TS 29.519) specifies the interface between PCF and UDR (Unified Data Repository). According to TS 29.519, specific resources are defined to control usage monitoring information. Usage monitoring information is stored according to the following structure: {apiRoot}/nudr-dr/v1/policy-data{ueId}/sm-data/{usageMonId}.

[008] The PCF may create a usage monitor resource to store the remaining usage for UsageMonId. This resource may be deleted when the corresponding restriction no longer exists. The PCF may retrieve and modify the usage monitor information for a UE id and UsageMonId at any time during the lifetime of the PDU session.

[009] It is not specified how the PCF obtains the usageMonId or how the usageMonId relates to information in the usage limits (UsageMonDataLimit data type) or monitoring data (UsageMonData).

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

[0011] It can be assumed that the "UsageMonId" variable field corresponds to a monitoring key that the PCF uses to monitor traffic to the SMF. However, if a monitoring key is used in "usageMonId", it is necessary to limit the scope of the currently defined monitoring keys (i.e. per UE and per DNN). A new scope of monitoring key values could be considered:

[0012] 1) Scope of monitoring key values per S-NSSAI/DNN pair. However, scope of monitoring key values per S-NSSAI/DNN pair may limit the possibility of accumulating usage fees for different S-NSSAI/DNN combinations. Furthermore, the following modification to the current specification would be required: individual resources of UsageMonitoringInformation can represent accumulated usage information corresponding to different restrictions. As a result, UsageMonData needs to be updated to include S-NSSAI/DNN information, and PATCH method should be used instead of PUT to maintain a high degree of control during storage updates.

[0013] 2) The scope of monitoring key values is determined by each restriction definition, so that DNN/S-NSSAI pairs that fall under the same restriction definition are assigned the same monitoring key value, and different restrictions always assign different monitoring key values. If this is implemented, the current way of defining monitoring keys will be restricted, and the accumulated usage will be linked to the monitoring usage in SMF. The following impact will need to be considered: Each UsageMonitoringInformation resource represents accumulated usage information corresponding to a certain restriction. That is, DNN/S-NSSAI information is not related to the UsageMonitoringInformation resource. This is because DNN/S-NSSAI information is taken into account in the restriction definition of the Sm-Data resource. The S-NSSAI/DNN query parameters can be removed.

[0014] 3) Scope the monitoring key per deployment so that the monitoring key value is unique. This ensures that each UsageMonitoringInformation resource represents the accumulated usage information corresponding to the latest update of the S-NSSAI/DNN pair. In other words, the DNN/S-NSSAI information is not related to the UsageMonitoringInformation resource, because the DNN/S-NSSAI information is taken into account in the restriction definition of the Sm-Data resource, which already contains the monitoring key. The S-NSSAI/DNN query parameters can be removed and each UsageMonitoringInformation resource will not contain the exact restriction information, but the residual value at the time of the last PDU session update.

[0015] Both of these potential approaches limit how monitoring keys are used today by decoupling their use in the context of SMF/UPF usage monitoring from the storage methods implemented in user databases.

[0016] Therefore, the present disclosure proposes to use an identifier that identifies a certain usage limit in the "usageMonId" resource identifier (e.g., URI) variable. This identifier may be called the "Accumulator/Limit Identifier" or ("limitId" for short). Each UsageMonitoringInformation resource represents accumulated usage information corresponding to a given limit identified by the limit identifier. Therefore, there is no restriction on the definition of the monitoring key value. The present approach requires the inclusion of limitId in the UsageMonDataLimit and UsageMonData data types. The advantage of the proposed approach is that it provides the most flexibility with respect to the current scope of the monitoring key. The proposed approach also allows for decoupling the use of the monitoring key from the accumulation method in the UDR, further allowing for a flexible model of the accumulation method. Since there is no restriction on the definition of the monitoring key, various business models are possible that accumulate for different combinations of DNN and S-NSSAI. Furthermore, it has the advantage of not affecting the defined usage monitoring method.

[0017] Thus, in one aspect, a method is provided that includes a policy function (e.g., PCF) sending an information request to a depository function (e.g., UDR). The method also includes the policy function receiving a response, the response having a UsageMonDataLimit instance having a limit identifier and a UsageMonData instance corresponding to the UsageMonDataLimit instance, the UsageMonData instance also having the limit identifier.

[0018] In some embodiments, the method further includes, prior to sending the request, the policy function receiving a request from the management function and the policy function determining in response to the request whether the policy function needs to fetch information from the depository function.

[0019] In some embodiments, the method further includes the policy function sending a request to the depository function requesting the depository function to provide a notification to the policy function when a change occurs to a UsageMonData instance associated with the UsageMonDataLimit instance.

[0020] In some embodiments, the method further includes the policy function sending an update request to the depository function. In some embodiments, the update request is an HTTP PATCH request with a UsageMonData instance having the restriction identifier, or the update request is an HTTP PUT request with a resource identifier (e.g., a URI) having the restriction identifier.

[0021] In some embodiments, the method further includes the policy function sending an unsubscribe request to the depository function, where sending the unsubscribe request includes sending an HTTP PUT request having a body with a resource identifier having the restriction identifier.

[0022] In some embodiments, the UsageMonDataLimit instance further includes at least one of a usage monitor level instance indicating whether the UsageMonDataLimit instance applies at the PDU session level or the service level, start date information indicating a start date and time, end date information indicating an end date and time, a usage limit threshold indicating a maximum allowable traffic volume, or a reset period used to indicate when the allowable usage volume should be reset.

[0023] In some embodiments, the UsageMonDataLimit instance further has a data scope that indicates the combination of S-NSSAI and DNN to which the UsageMonDataLimit instance applies.

[0024] 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 the PDU session level or at the service level, or an allowable usage value, where the allowable usage value indicates the remaining allowable traffic volume and/or the amount of time remaining.

[0025] In some embodiments, the usageMonData instance further includes information indicating the time at which the allowed usage is reset to the usage limit threshold.

[0026] In another aspect, a method is provided, the method including a depository function (e.g., a UDR) receiving a request for information from a policy function (e.g., a PCF). The method also includes the depository function sending a response in response to the request, the response having a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier.

[0027] In some embodiments, the method further includes the depository function receiving an update request from the policy function. In some embodiments, the update request is an HTTP PATCH request with a UsageMonData instance having the restriction identifier, or the update request is an HTTP PUT request with a resource identifier (e.g., a URI) having the restriction identifier.

[0028] In some embodiments, the method further includes the depository function receiving an unsubscribe request from the policy function. In some embodiments, the unsubscribe request is an HTTP PUT request having a body with a resource identifier having a restriction identifier.

[0029] In some embodiments, the usageMonDataLimit instance further includes at least one of a usage monitor level instance indicating whether the usageMonDataLimit instance applies at the PDU session level or the service level, start date information indicating a start date and time, end date information indicating an end date and time, a usage limit threshold indicating a maximum allowable traffic volume, or a reset period used to indicate when the allowable usage volume should be reset.

[0030] In some embodiments, the usageMonDataLimit instance further has a data scope that indicates the combination of S-NSSAI and DNN to which the usageMonDataLimit instance applies.

[0031] 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 the PDU session level or at the service level, or an allowable usage value, where the allowable usage value indicates the remaining allowable traffic volume and/or the amount of time remaining.

[0032] In some embodiments, the usageMonData instance further includes information indicating the time at which the allowed usage is reset to the usage limit threshold.

[0033] In another aspect, a computer program is provided having instructions that, when executed by processing circuitry of the device, cause the device to perform the method described herein. In another aspect, a carrier is provided that includes the computer program described in the preceding paragraph, the carrier being one of an electronic signal, an optical signal, a radio signal, and a computer-readable storage medium.

[0034] In another aspect, a policy function device is provided. The policy function device is adapted to send a request for information to a depository function and receive a response to the request. The response includes a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, where the usageMonData instance also has the limit identifier.

[0035] In another aspect, a depository function device is provided. The depository function device is adapted to receive a request for information from a policy function and to send a response in response to the request from the policy function. The response includes a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, where the usageMonData instance also has the limit identifier.

[0036] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments.
[0037] Figure 1 shows an example of a resource structure. [0038] FIG. 2 is an example of a flow diagram. [0039] FIG. 3 is an example of a message flow diagram. [0040] FIG. 4 is a flow chart illustrating a procedure according to one embodiment. [0041] FIG. 5 is a flow chart illustrating a procedure according to one embodiment. [0042] Figure 6 is a block diagram of an apparatus according to one embodiment.

[0043] As mentioned above, TS 29.519 specifies the interface between the PCF and the UDR. According to TS 29.519, specific resources are defined to control the usage monitoring information. The usage monitoring information is stored according to the following structure: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}. The resource structure is shown in Figure 1.

[0044] The solution proposed here requires modifications to the current version of TS 29.519. Clause 5.4.2 of TS 29.519 defines various structured data types. One of the defined structured data types is the "UsageMonDataLimit" type, which is defined in table 5.4.2.6-1 of TS 29.519. This table is shown below.

[0045] The UsageMonDataLimit type may change over time to include other attributes. For example, the UsageMonDataLimit type may further include an attribute named "scopes". The "scopes" attribute is of type UsageMonDataScope and contains information that identifies the S-NSSAI and DNN combination to which the usageMonDataLimit instance applies.

[0046] This disclosure proposes to modify the definition of the UsageMonDataLimit type to include an attribute named "limitId". The limitId attribute has a data type of "string", is mandatory (M), and has cardinality of 1. The description of this new attribute is "Identifies the limit". That is, the limitId attribute identifies the usage monitor control instance.

[0047] Another structured data type defined is the "UsageMonData" type, which is currently defined in Table 5.4.2.7-1 of TS 29.519, as shown below.

[0048] This disclosure proposes to replace the "monKey" attribute with an attribute named "limitId". The limitId attribute has data type "string", is mandatory (M) and has cardinality 1. The description of this new attribute is as follows: It specifies the limit defined in the "limitId" attribute of the UsageMonDataLimit data type (see TS 29.519, clause 5.4.2.6).

[0049] The UsageMonData type may change over time to include other attributes. For example, the UsageMonData type may include an attribute named "resetTime". The "resetTime" attribute is of type DateTime and contains information indicating the time to reset the allowed usage back to the usageLimit of the corresponding UsageMonDataLimit.

[0050] The "UsageMonitoringInformation" resource is described in TS 29.519, clause 5.2.6. As described in TS 29.519, clause 5.2.6.1, the UsageMonitoringInformation "resource represents an individual usage monitoring resource created in a UDR and associated with a ueId and usageMonId."

[0051] Clause 5.2.6.2 of TS 29.519 defines "Resource definition". Specifically, this clause specifies the resource identifier for a resource as "{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}". Clause 5.2.6.2 of TS 29.519 currently defines the variables apiRoot, ueId, and usageMonId as shown in the following table (corresponding to table 5.2.6.2-1 of TS 29.519):

[0052] This disclosure further extends the definition of usageMonId so that the usageMonId variable is not only a "unique identifier for an 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 described above. This disclosure further proposes to modify the technical specification so that the GET method on the UsageMonitoringInformation resource does not support URI query parameters.

[0053] FIG. 2, for example, is a message flow diagram showing PCF 202 communicating with UDR 204. UDR 204 is a subscriber repository where PCF 202 stores and retrieves policy data for users, S-NSSAIs, and DNNs. Details of the interaction with UDR in PCC flows are specified in C3-186391 (currently available at www.3gpp.org/FTP/Meetings_3GPP_SYNC/CT3/Inbox/C3-186391.zip).

[0054] The procedure shown in FIG. 2 is for both roaming and non-roaming scenarios. In the case of home routed roaming, PCF 202 acts as an H-PCF. In the case of LBO roaming, PCF 202 acts as a V-PCF and steps 2 to 4 may be skipped.

[0055] Step 1: SMF 201 receives a PDU session establishment request from a user equipment (UE). That is, SMF 201 receives a PDU session establishment request sent by the UE towards the SMF. SMF 201 selects a PCF as described in clause 8.3 of TS 29.513 and invokes the Npcf_SMPolicyControl_Create service operation by sending an HTTP POST request to the resource URI "{apiRoot}/npcf-smpolicycontrol/v1/sm-policies". The request operation provides the SUPI, PDU Session ID, PDU Session Type, DNN, and S-NSSAI, and can provide the GPSI, Internal Group Identifier, Access Type, IPv4 Address or IPv6 Network Prefix (if available), PEI if received at the SMF 201, User Location Information, UE Time Zone, Serving Network, RAT Type, Charging Information, Subscription Session-AMBR, and Subscription Default 5QI/ARP (if available). The request operation further includes a notification URI to instruct the PCF where to send notifications when SM related policies are updated.

[0056] Step 2: PCF 202 determines whether it has subscription data for the SUPI and DNN. If PCF 202 does not have subscription data for the SUPI and DNN, PCF 202 invokes the Nudr_DataRepository_Query service operation to UDR 204 (e.g., PCF 202 sends an HTTP GET request to UDR 204 specifying the resource URI: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data, as specified in TS 29.519).

[0057] Step 3: The UDR 204 receives the GET request and then sends an HTTP "200 OK" response to the PCF 202. The response contains the resources under {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data, including the UsageMonDataLimit application instance with the limit definition and the UsageMonData application instance with the usage consumption information.

[0058] Note that UsageMonDataLimit instances are stored in the .../sm-data resource and UsageMonData instances are stored in the /{usageMonId} resource, and both are retrieved using a GET request to the .../sm-data resource URI.

[0059] Each UsageMonDataLimit instance contains a "limitId" attribute that identifies the name of the limit (e.g., "limitId": "Facebook-limit") along with a defined usageLimit (e.g., "UsageLimit": "500MB") and other optional parameters.

[0060] Each UsageMonData instance includes a "limitId" attribute that identifies the name of the limit (e.g., "limitId": "Facebook-limit"), along with the remaining usage in the "allowedUsage" attribute (e.g., "allowedUsage": "200MB").

[0061] UDR 204 provides UsageMonData for each existing {usageMonId}. UsageMonData contains limitId instead of monitoringKey.

[0062] Step 4: When PCF 202 receives the response sent by UDR 204, PCF 202 detects whether the response includes a UsageMonDataLimit instance for the UE. If PCF 202 detects that a UsageMonDataLimit exists for the UE, PCF 202 may request UDR 204 to provide notifications to PCF 202 when a change occurs to a UsageMonData instance associated with the UsageMonDataLimit instance (i.e., a UsageMonData instance that is included in the UsageMonDataLimit instance and includes the same limitId as the limitId identifying the UsageMonDataLimit instance). PCF 202 requests these notifications from UDR 204 by invoking the Nudr_DataRepository_Subscribe service operation (e.g., by sending UDR 204 an HTTP message with URI: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}), where "UsageMonId" is the "limitId" contained in the received UsageMonDataLimit instance. Note that PCF 202 may also subscribe to receive change notifications for data represented in the sm-data resource.

[0063] Step 5: UDR 204 sends an HTTP "201 Created" response to confirm the subscription from PCF 202.

[0064] Step 6: If PCF 202 determines that the policy decision depends on the status of policy counters available at CHF 206 and such reporting has not been established for the subscriber, PCF 202 initiates an Initial Spending Limit Report Retrieval as defined in 3GPP TS 29.594 V15.1.0, section 5.3.2. If PCF 202 determines that policy counter status reporting has already been established for the subscriber and further policy counter status is required, PCF 202 initiates an Intermediate Spending Limit Report Retrieval as defined in 3GPP TS 29.594 V15.1.0, section 5.3.3.

[0065] Step 7: PCF 202 evaluates the information provided in step 6 and makes a policy decision.

[0066] Step 8: PCF 202 sends an HTTP "201 Created" response to SMF 201 with the determined policy as described in 3GPP TS 29.512 V15.1.0, section 4.2.2. After this step, PCF 202 can subscribe to SMF 201 events associated with the PDU session.

[0067] Figure 3 is another message flow diagram showing communication between various functions, including PCF 202 and UDR 204.

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

[0069] Step 2: Upon receiving the Npcf_SMPolicyControl_Delete service operation, the PCF identifies the PCC rules that need to be notified to AF301 and deletes the PCC rules related to the PDU session.

[0070] Step 3: SMF201 deletes all PCC rules applied to the PDU session.

[0071] Step 4: PCF 202 invokes the Npcf_PolicyAuthorization_Notify service operation, if requested by AF 301, by sending an HTTP POST request to AF 301 using "{notifUri}/notify" as the resource URI to indicate that no send resource exists for the service.

[0072] Step 5: AF301 sends an HTTP "204 No Content" response to PCF202.

[0073] Step 6: AF 301 invokes the Npcf_PolicyAuthorization_Delete service operation by sending an HTTP POST request to the resource URI "{apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId}/delete". The request may include the event to subscribe to.

[0074] Step 7: PCF 202 deletes the AF application session context and sends an HTTP "204 No Content" response to the AF. If PCF 202 needs to report usage data or access network information, PCF 202 sends an HTTP "200 OK" response. If the usage threshold was previously provided by the AF and PCF 202 has usage data that has not yet been reported to the AF, PCF 202 informs AF 301 about the resources consumed by the user since the last report. Also, if SMF 201 reported access network information in step 1 and AF 301 previously requested PCF 202 to report access network information, PCF 202 informs AF 301 of the access network information. PCF 202 also deletes the subscription of the event detected by PCF 202 for that AF application session.

[0075] Step 4a: PCF 202 instructs AF 301 to terminate the session by sending a diameter ASR to AF 301.

[0076] Step 5a: AF 301 responds by sending a diameter ASA to PCF 202.

[0077] Step 6a: AF 301 sends a diameter STR to PCF 202 to indicate that the session has ended.

[0078] Step 7a: PCF 202 responds by sending a diameter STA to AF 301. Steps 4a, 5a, 6a, and 7a are for the "Rx" case, i.e., PCF 202 supports an Rx interface with AF 301. Details of the Rx interface are described in 3GPP TS 29.214 V15.4.0.

[0079] Step 8: If this is the last PDU session for this subscriber, a Final Spending Limit Report Request as defined in 3GPP TS 29.594 V15.1.0, clause 5.3.4 is sent. If any of the existing PDU sessions for this subscriber require a policy counter status report, an Intermediate Spending Limit Report Request as defined in 3GPP TS 29.594 V15.1.0, clause 5.3.3 can be sent to change the list of subscribed policy counters.

[0080] Step 9: PCF202 deletes the PCC rule for the terminated PDU session and sends an HTTP "204 No Content" response to SMF201.

[0081] Step 10: At the end of the SM policy association, PCF 202 updates the remaining usage in the UDR for applicable limits. PCF 202 can send a PATCH request to the .../sm-data resource URI with the updated value of the remaining usage in the "allowedUsage" attribute contained in the corresponding "UsageMonData" instance, where each "UsageMonData" instance is identified by its "limitId" (e.g., "limitId": "Facebook-limit" and "allowedUsage": "125MB"). Alternatively, PCF 202 can send a PUT request to the .../{usageMonId} resource URI for each "UsageMonData" instance that PCF 202 needs to update. The value of "UsageMonId" is the value of "limitId" (e.g., .../facebook-limit resource URI for Facebook consumption, .../netflix-premium resource URI for Netflix Premium consumption, etc.). The UDR stores the remaining usage associated with the limitId (instead of using a monitor key).

[0082] Step 11: UDR 204 sends an HTTP "204 No Content" response to PCF 202.

[0083] Step 12: PCF 202 may unsubscribe to receive changes related to Resource ID .../{usageMonId} identified by limitId. Note that PCF 202 may unsubscribe to receive change notifications for data represented by sm-data resource. To end subscription to changes in usage monitoring data represented by .../{usageMonId}, PCF 202 may send a PUT request to 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 will not include the aforementioned .../{usageMonId} resource URI. Alternatively, PCF 202 may terminate the subscription to notifications for any data changes by sending a DELETE request to the {apiRoot}/nudr-dr/v1/policy-data/subs-to-notify resource URI.

[0084] Step 13: UDR 204 sends an HTTP "204 No Content" response to PCF 202.

[0085] FIG. 4 is a flow chart illustrating a procedure 400 according to one embodiment. Procedure 400 may begin at step s402.

[0086] Step s402 involves a policy function (e.g. PCF 202) receiving a request 251 (see FIG. 2) from a management function (e.g. SMF 201), the request relating to a UE. That is, the management function has sent the request 251 towards the policy function such that the policy function receives the request (directly or indirectly) from the management function.

[0087] Step s404 involves the policy function determining whether it needs to fetch information related to the UE from a depository function (e.g., UDR 204). If the policy function needs to fetch information, procedure 400 proceeds to step 406, otherwise, procedure 400 proceeds to step 410.

[0088] Step s406 includes the policy function sending a request 252 for information to the depository function. That is, for example, in an embodiment in which the policy function is implemented in software, the software instructs the hardware on which it runs to send the request 252.

[0089] Step s408 includes the policy function receiving a response 254 to the request. The response was sent by the depository function and includes a usageMonDataLimit instance that includes a limit identifier, and a usageMonData instance that corresponds to the usageMonDataLimit instance. The usageMonData instance also includes the limit identifier. When the policy function receives a 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 a UsageMonDataLimit exists for the UE, the policy function performs step s409.

[0090] Step s409 includes the policy function sending a request 256 to the depository function to provide notification when a change occurs to the UsageMonData instance associated with the UsageMonDataLimit instance.

[0091] Step s410 includes the policy function sending a response 260 to the management function.

[0092] Step s412 includes the policy function receiving (directly or indirectly) a request 302 to delete the SM-related policy context from the management function.

[0093] Step s414 includes the policy function sending the update request 304 to the depository function (e.g., HTTP PATCH or PUT as described above with respect to step 10 of FIG. 3).

[0094] Step s416 includes the policy function sending an unsubscription request 306 to the depository function, as described above with respect to step 12 of FIG. 3.

[0095] FIG. 5 is a flow chart illustrating a procedure 500 according to one embodiment. Procedure 500 may begin at step s502.

[0096] Step s502 includes a depository function (e.g., UDR 204) receiving a request 252 for information from a policy function (e.g., PCF 202).

[0097] Step s504 includes the depository function sending a response 254 in response to the request 252. The response includes a usageMonDataLimit instance having a limit identifier and a usageMonData instance that corresponds to the usageMonDataLimit instance, where the usageMonData instance also has the limit identifier.

[0098] Step s506 includes the depository function receiving an update request 304 (e.g., an HTTP PATCH or PUT as described above with respect to step 10 of FIG. 3) from the policy function.

[0099] Step s508 includes the depository function receiving an unsubscription request 306 from the policy function, as described above with respect to step 12 of FIG. 3.

[00100] FIG. 6 is a block diagram of an apparatus 601 for implementing PCF 202 or UDR 204, according to some embodiments. For example, in embodiments in which PCF 202 and/or UDR 204 are comprised of software (e.g., script and/or compiled code), apparatus 601 may execute the PCF/UDR software. Thus, apparatus 601 may be referred to as a policy function apparatus in embodiments in which apparatus 601 executes PCF software. Similarly, apparatus 601 may be referred to as a depository function apparatus in embodiments in which apparatus 601 executes UDR software. As shown in FIG. 6, apparatus 601 may have a processing circuit (PC) 602. Processing circuit 602 may include one or more processors (P) 655 (e.g., one or more general-purpose microprocessors and/or one or more other processors, such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc.). These processors may be located in a single housing or a single data center, or may be geographically distributed. The device 601 may also have a network interface 648. The network interface 648 has a transmitter (Tx) 645 and a receiver (Rx) 647 to allow the device 601 to transmit and receive data to and from other nodes connected to the network 110 (e.g., an Internet Protocol (IP) network) to which the network interface 648 is connected. The device 601 may also have a local storage unit 608, also referred to as a "data storage system." The local storage unit 608 may include one or more non-volatile storage devices and/or one or more volatile storage devices. In embodiments in which the PC 602 includes a programmable processor, a computer program product (CPP) 641 may be provided. The CPP 641 includes a computer readable medium (CRM) 642 that stores a computer program (CP) 643 having computer readable instructions (CRI) 644. CRM 642 may be a non-transitory computer-readable medium, such as a magnetic medium (e.g., a hard disk), an optical medium, a memory device (e.g., a random access memory, a flash memory), or the like. In some embodiments, CRI 644 of computer program 643, when executed by PC 602, is configured such that CRI causes device 602 to perform steps described herein (e.g., steps described herein with respect to flow charts). In other embodiments, device 601 may be configured to perform steps described herein without the need for code. That is, for example, PC 602 may be comprised solely of one or more ASICs. Thus, the functionality of the embodiments described herein may be implemented by hardware and/or software.

[00101] Implementation
A1. A method (400) comprising a policy function (e.g., PCF 202) sending (s406) a request for information (252) to a depository function (e.g., UDR 204), where the depository function is configured to send a response (254) in response to the request, and the policy function receiving (s408) the response, where the response has a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, where the usageMonData instance also has the limit identifier.

[00103] A2. The method of embodiment A1, further comprising, prior to sending the request (252), the policy function receiving the request (251) sent by the management function (e.g., SMF) and determining (s404) whether the policy function needs to fetch information from the depository function.

[00104] B1. A method, comprising: a depository function (e.g., UDR 204) receiving a request for information sent by a policy function (e.g., PCF 202); and the depository function sending a response in response to the request, the response having a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier.

[00105] B2. The method of embodiment B1, further comprising the depository function receiving (s506) the update request (304) sent by the policy function.

[00106] B3. The method of embodiment B2, wherein the update request is an HTTP PATCH request with a UsageMonData instance having a restriction identifier.

[00107] B4. The method of embodiment B2, wherein the update request is an HTTP PUT request having a resource identifier (e.g., a URI) having a restriction identifier.

[00108] B5. The method of any one of embodiments B1 to B4, further comprising the depository function receiving (s508) the unsubscribe request (306) sent by the policy function.

[00109] B6. The method of embodiment B5, wherein the unsubscribe request is an HTTP PUT request having a body with a resource identifier having a restriction identifier.

[00110] C1. An apparatus (601) adapted to send (s406) a request for information (252) to a depository function (e.g., UDR 204), where UDR 204 is configured to send a response (254) in response to the request, and receive (s408) the response, where the response has a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, where the usageMonData instance also has the limit identifier.

[00111] C2. The device of embodiment A1, further adapted to determine (s404) whether information needs to be fetched from the depository function before sending the request (252) and after receiving the request (251) sent by the management function.

[00112] D1. A device (601) adapted to receive a request for information sent by a policy function (e.g., PCF 202) and to send a response in response to the request, the response having a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier.

[00113] D2. The apparatus of embodiment D1, further adapted to perform the method of any one of embodiments B2 to B6.

[00114] The following describes the changes to TS 29.519 proposed in this specification.
[00115] First modification
[00116] 5.2.6.2 Resource Definitions
[00117] Resource URI: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}

[00118] This resource MUST support the resource URI variables defined in the table below.

[00119] Second modification
[00120] 5.2.6.3.3 GET
[00121] This method MUST support the URI query parameters specified in the table below.

[00122] While various embodiments have been described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, all possible combinations of the elements described above, in all variations thereof, are encompassed by the present disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[00123] Moreover, while the procedures described above and illustrated in the drawings are shown as a series of steps, this is for illustrative purposes only. It is therefore contemplated that steps may be added, steps omitted, the order of steps rearranged, and steps performed in parallel. Also, the phrase "receive from" should be interpreted as including "receive directly from" or "receive indirectly from." That is, a first entity receives a message from a second entity even if a third entity receives the message sent by the second entity and forwards the message to the first entity.

[00124] Abbreviations
[00125] AF Application Function
[00126] AMBR Aggregate Maximum Bit Rate
[00127] APN Access Point Name
[00128] ARP Allocation and Retention Priority
[00129] ASA Abort Session Answer
[00130] ASR Abort Session Request
[00131] CHF billing function
[00132] DNN Data Network Name
[00133] HTTP Hypertext Transfer Protocol
[00134] IP-CAN: IP-connectable access network
[00135] GPSI Universal Public Subscriber Identifier
[00136] H-PCF Home Policy Control Function
[00137] PCC Policy and Charging Control
[00138] PCF Policy Control Function
[00139] PCRF Policy and Charging Rules Function
[00140] PDU Protocol Data Unit
[00141] PEI Permanent Equipment Identifier
[00142] PGW Packet Data Network Gateway
[00143] RAT Radio Access Technology
[00144] SM Short Message(?)
[00145] SMF Session Management Function
[00146] SPR Subscription Profile Repository
[00147] STA Session Termination Response
[00148] STR Session termination request
[00149] SUPI Subscription Permanent Identifier
[00150] S-NSSAI Single network slice selection assistance information
[00151] UDR Unified Data Repository
[00152] UP User Plane
[00153] UPF User Plane Function
[00154] V-PCF Destination Policy Control Function
[00155] 5QI 5G Quality of Service (QoS) Identifier

Claims (25)

1. A method (400), comprising:
The policy function (202) sends (s406) a request (252) for information to the depository function (204);
and receiving (s408) a response (254) to the request by the policy function (202), the response (254) comprising:
a usageMonDataLimit instance having a limit identifier;
and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier. 10. The method of claim 1 further comprising:
said policy function receiving (s402) a request (251) from a management function (201) before sending said request (252);
and the policy function (202) determining (s404) in response to the request (251) whether the policy function (202) needs to fetch the information from the depository function. The method of claim 1 or 2, further comprising the policy function (202) sending a request (256) to the depository function requesting the depository function to provide a notification to the policy function when a change occurs to the UsageMonData instance associated with the UsageMonDataLimit instance. The method of any one of claims 1 to 3, further comprising the policy function (202) sending an update request (304) to the depository function (204). 5. The method of claim 4,
The update request (304) is an HTTP PATCH request with a UsageMonData instance that has the restriction identifier, or
The method of claim 1, wherein the update request (304) is an HTTP PUT request having a resource identifier that has a restriction identifier. The method of any one of claims 1 to 5, further comprising the policy function (202) sending an unsubscription request (306) to the depository function (204), wherein sending the unsubscription request comprises sending an HTTP PUT request having a body with a resource identifier having the restriction identifier. 7. The method of claim 1, wherein the usageMonDataLimit instance comprises:
a usage monitor level instance indicating whether the usageMonDataLimit instance applies at the PDU session level or at the service level;
Start date information indicating the start date and time;
End date information indicating the end date and time,
a usage limit threshold indicating a maximum allowable traffic volume; or a reset period used to indicate when the allowable usage should be reset. The method of any one of claims 1 to 7, wherein the usageMonDataLimit instance further includes a data coverage indicating a combination of S-NSSAI and DNN to which the usageMonDataLimit instance applies. 9. The method of claim 1, wherein the usageMonData instance:
a usage monitor level (umLevel) instance indicating whether the usageMonData instance applies at a PDU session level or a service level; or an allowed usage value, the allowed usage value indicating a remaining allowed amount of traffic, and/or the allowed usage value indicating an amount of time remaining. The method of any one of claims 7 to 9, wherein the usageMonData instance further includes information indicating a time to reset the allowable usage to the usage limit threshold. 1. A method (500), comprising:
A depository function (204) receives (s502) a request (252) for information from a policy function (202);
and in response to the request from the policy function (202), the depository function (204) sends (s504) a response (254), the response (254) comprising:
a usageMonDataLimit instance having a limit identifier;
and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier. The method of claim 11, further comprising the depository function receiving (s506) an update request (304) sent by the policy function. 13. The method of claim 12,
The update request (304) is an HTTP PATCH request with a UsageMonData instance that has the restriction identifier, or
The method of claim 1, wherein the update request (304) is an HTTP PUT request having a resource identifier that has the restriction identifier. The method of any one of claims 11 to 13, further comprising the depository function receiving (s508) an unsubscription request (306) from the policy function. The method of claim 14, wherein the unsubscribe request is an HTTP PUT request having a body with a resource identifier that has the restriction identifier. 16. The method of claim 11, wherein the usageMonDataLimit instance further comprises:
a usage monitor level instance indicating whether the usageMonDataLimit instance applies at the PDU session level or at the service level;
Start date information indicating the start date and time;
End date information indicating the end date and time,
a usage limit threshold indicating a maximum allowable traffic volume; or a reset period indicating a time at which the allowable usage is to be reset. The method of any one of claims 11 to 16, wherein the usageMonDataLimit instance further includes a data coverage indicating a combination of S-NSSAI and DNN to which the usageMonDataLimit instance applies. 18. The method of any one of claims 11 to 17, wherein the usageMonData instance further comprises:
a usage monitor level (umLevel) instance indicating whether the usageMonData instance applies at a PDU session level or at a service level; or an allowed usage value, the allowed usage value indicating a remaining allowed traffic volume, and/or the allowed usage value indicating an amount of time remaining. The method of any one of claims 17 to 18, wherein the usageMonData instance further includes information indicating a time to reset the allowed usage to the usage limit threshold. A computer program (643) having instructions (644) that, when executed by a processing circuit (602) of an apparatus (600), causes the apparatus (600) to perform a method according to any one of claims 1 to 19. A carrier containing the computer program of claim 20, the carrier being one of an electronic signal, an optical signal, a radio signal, and a computer-readable storage medium (642). A policy function device (601),
Sending a request (252) for information to a depository function (204);
adapted to receive a response (254) to said request;
A policy function apparatus, wherein the response (254) comprises a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier. A policy function device as claimed in claim 22, further adapted to execute a method as claimed in any one of claims 2 to 10. A depository functional device (601),
receiving a request for information (252) from a policy function (202);
adapted to send a response (254) in response to said request from said policy function (202);
The response (254) comprises a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier. The depository function device according to claim 24, further adapted to perform the method according to any one of claims 12 to 19.

Images