Usage amount monitor data control

Abstract

To provide a method for managing usage amount monitor data, a program, a method, a policy device, and a depository function device.SOLUTION: The method for managing usage amount monitor data includes the steps in which: a policy function sends a request for information to a depository function (s406); and the policy function receives a response to the request (s408). The response includes: a usageMonDataLimit instance having a restriction identifier; and a usageMonData instance corresponding to the usageMonDataLimit instance. The usageMonData instance also has a restriction identifier.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] This disclosure relates to managing usage monitoring data. [Background technology]

[0002]

[0002] 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.

[0003]

[0003] 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.

[0004]

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

[0005]

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

[0006]

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

[0007]

[0007] 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. The usage monitoring information is stored according to the following structure: {apiRoot} / nudr-dr / v1 / policy-data{ueId} / sm-data / {usageMonId}.

[0008]

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

[0009]

[0009] 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]

[0010] In the resource definition of the UsageMonitoringInformation resource, it is not clearly defined 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", the scope of the currently defined monitoring key (i.e. per UE and per DNN) needs to be restricted. A new scope of values ​​for the monitoring key could be considered:

[0012]

[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 high control during storage updates.

[0013]

[0013] 2) The scope of the monitoring key value is determined for each restriction definition, and the same monitoring key value is assigned to DNN / S-NSSAI pairs that fall under the same restriction definition, and different monitoring key values ​​are always assigned when the restrictions are different. 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 resource of UsageMonitoringInformation 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]

[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. This is 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 be the exact restriction information, but will contain the residual value at the time of the last PDU session update.

[0015]

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

[0016]

[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 "Accumulator / Limit Identifier" or ("limitId" for short). Each resource of UsageMonitoringInformation represents accumulated usage information corresponding to a given limit identified by the limit identifier. Therefore, there is no restriction on the definition of the value of the monitoring key. 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, and further allows 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]

[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]

[0018] In some embodiments, the method further includes, before 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]

[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 with the restriction identifier, or the update request is an HTTP PUT request with a resource identifier (e.g., a URI) with the restriction identifier.

[0021]

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

[0022]

[0022] In some embodiments, the UsageMonDataLimit instance further has 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 the time when the allowable usage should be reset.

[0023]

[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]

[0024] In some embodiments, the UsageMonData instance further has at least one of a usage monitoring level (umLevel) instance indicating whether the usageMonData instance applies at the PDU session level or the service level, or an allowed usage value, where the allowed usage value indicates the remaining allowed traffic volume and / or the amount of remaining time.

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

[0026]

[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]

[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]

[0029] In some embodiments, the usageMonDataLimit instance further has at least one of a usage monitoring 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 the time when the allowable usage needs to be reset.

[0030]

[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]

[0031] In some embodiments, the usageMonData instance further has at least one of a usage monitoring level (umLevel) instance indicating whether the usageMonData instance applies at the PDU session level or the service level, or an allowed usage value, where the allowed usage value indicates the remaining allowed traffic volume and / or the amount of remaining time.

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

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

[0034]

[0034] In another aspect, a policy function apparatus is provided. The policy function apparatus 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, the usageMonData instance also having the limit identifier.

[0035]

[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 has a usageMonDataLimit instance having a limit identifier and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier. [Brief description of the drawings]

[0036]

[0036] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various embodiments. [Figure 1]

[0037] FIG. 1 shows an example of a resource structure. [Diagram 2]

[0038] FIG. 2 is an example of a flow diagram. [Diagram 3]

[0039] FIG. 3 is an example of a message flow diagram. [Figure 4]

[0040] FIG. 4 is a flow chart illustrating a procedure according to one embodiment. [Diagram 5]

[0041] FIG. 5 is a flow chart illustrating a procedure according to one embodiment. [Figure 6]

[0042] FIG. 6 is a block diagram of an apparatus according to one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0037]

[0043] As mentioned above, TS 29.519 specifies the interface between PCF and UDR. 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}. The resource structure is shown in Figure 1.

[0038]

[0044] The solution proposed here requires changes 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. [Table 2]

[0039]

[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.

[0040]

[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 1. The description of this new attribute is "Identifies the limit". That is, the limitId attribute identifies the usage monitor control instance.

[0041]

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

[0042]

[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).

[0043]

[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 about the time to reset the allowed usage back to the usageLimit of the corresponding UsageMonDataLimit.

[0044]

[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."

[0045]

[0051] Clause 5.2.6.2 of TS 29.519 specifies "Resource definitions". Specifically, this section 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): [Table 4]

[0046]

[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 mentioned 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.

[0047]

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

[0048]

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

[0049]

[0055] Step 1: The SMF 201 receives a PDU session establishment request from a user equipment (UE). That is, the SMF 201 receives a PDU session establishment request sent by the UE towards the SMF. The 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 may provide the GPSI, Inner Group Identifier, Access Type, IPv4 Address or IPv6 Network Prefix (if available), PEI if received by 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.

[0050]

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

[0051]

[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 resources under {apiRoot} / nudr-dr / v1 / policy-data / {ueId} / sm-data, including a UsageMonDataLimit application instance with the limit definition and a UsageMonData application instance with the usage consumption information.

[0052]

[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 with a GET request to the ... / sm-data resource URI.

[0053]

[0059] Each UsageMonDataLimit instance includes 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.

[0054]

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

[0055]

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

[0056]

[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 for the UE exists, PCF 202 may request UDR 204 to provide notifications to PCF 202 when changes occur to UsageMonData instances associated with the UsageMonDataLimit instance (i.e., UsageMonData instances that are included in the UsageMonDataLimit instance and include the same limitId as the limitId that identifies the UsageMonDataLimit instance). PCF 202 requests these notifications from UDR 204 by invoking the Nudr_DataRepository_Subscribe service operation (e.g., by sending an HTTP message with the URI: {apiRoot} / nudr-dr / v1 / policy-data / {ueId} / sm-data / {usageMonId} to UDR 204). Here, "UsageMonId" is the "limitId" contained in the received UsageMonDataLimit instance. Note that the PCF 202 may subscribe to receive change notifications of the data represented in the sm-data resource.

[0057]

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

[0058]

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

[0059]

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

[0060]

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

[0061]

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

[0062]

[0068] Step 1: The SMF 201 invokes the Npcf_SMPolicyControl_Delete service operation by sending an 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.

[0063]

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

[0064]

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

[0065]

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

[0066]

[0072] Step 5: The AF 301 sends an HTTP “204 No Content” response to the PCF 202.

[0067]

[0073] Step 6: The 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.

[0068]

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

[0069]

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

[0070]

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

[0071]

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

[0072]

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

[0073]

[0079] Step 8: If this is the last PDU session for this subscriber, a Final Spending Limit Report Request is sent as defined in 3GPP TS 29.594 V15.1.0, section 5.3.4. 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, section 5.3.3 can be sent to change the list of subscribed policy counters.

[0074]

[0080] Step 9: The PCF 202 deletes the PCC rules for the terminated PDU session and sends an HTTP “204 No Content” response to the SMF 201.

[0075]

[0081] Step 10: At the time of SM policy association termination, the PCF 202 updates the remaining usage in the UDR for applicable limits. The PCF 202 may send a PATCH request to ... / sm-data resource URI with the updated value of the remaining usage in the "allowedUsage" attribute included in the corresponding "UsageMonData" instance, where each "UsageMonData" instance is identified by its "limitId" (e.g., "limitId": "Facebook-limit" and "allowedUsage": "125MB"). Alternatively, the PCF 202 may send a PUT request to ... / {usageMonId} resource URI for each "UsageMonData" instance that the PCF 202 needs to update, where 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 watch key).

[0076]

[0082] Step 11: The UDR 204 sends an HTTP “204 No Content” response to the PCF 202.

[0077]

[0083] Step 12: The PCF 202 may unsubscribe to receive changes related to the Resource ID ... / {usageMonId} identified by the limitId. Note that the PCF 202 may unsubscribe to receive change notifications for data represented by the sm-data resource. To end the subscription for usage monitoring data changes represented by ... / {usageMonId}, the PCF 202 may send a PUT request to the resource URI: {apiRoot} / nudr-dr / v1 / policy-data / subs-to-notify. The body of this PUT request will include a PolicyDataSubscription data structure with an updated list of "monitoredResourceUris", which will not include the aforementioned ... / {usageMonId} resource URI. Alternatively, the PCF 202 may end the subscription for notifications for any data changes by sending a DELETE request to the {apiRoot} / nudr-dr / v1 / policy-data / subs-to-notify resource URI.

[0078]

[0084] Step 13: The UDR 204 sends an HTTP “204 No Content” response to the PCF 202.

[0079]

[0085] 4 is a flow chart illustrating one embodiment of a procedure 400. The procedure 400 may begin at step s402.

[0080]

[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, i.e. 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.

[0081]

[0087] Step s404 includes 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, the procedure 400 proceeds to step 406, otherwise it proceeds to step 410.

[0082]

[0088] Step s406 includes the policy function sending a request 252 for information to the depository function, i.e., 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.

[0083]

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

[0084]

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

[0085]

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

[0086]

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

[0087]

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

[0088]

[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.

[0089]

[0095] 5 is a flow chart illustrating one embodiment of a procedure 500. The procedure 500 may begin at step s502.

[0090]

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

[0091]

[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.

[0092]

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

[0093]

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

[0094]

[0100] FIG. 6 is a block diagram of an apparatus 601 for implementing a PCF 202 or a UDR 204, according to some embodiments. For example, in embodiments in which the PCF 202 and / or the UDR 204 are comprised of software (e.g., scripts and / or compiled code), the apparatus 601 may execute the PCF / UDR software. Thus, the apparatus 601 may be referred to as a policy function apparatus in embodiments in which the apparatus 601 executes the PCF software. Similarly, the apparatus 601 may be referred to as a depository function apparatus in embodiments in which the apparatus 601 executes the UDR software. As shown in FIG. 6, the apparatus 601 may have a processing circuit (PC) 602. The 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 apparatus 601 may also have a network interface 648. The network interface 648 includes a transmitter (Tx) 645 and a receiver (Rx) 647 for enabling 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 include 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.The CRM 642 may be a non-transitory computer readable medium, such as a magnetic medium (e.g., hard disk), an optical medium, a memory device (e.g., random access memory, flash memory), etc. In some embodiments, the CRI 644 of the computer program 643, when executed by the PC 602, is configured such that the CRI causes the device 602 to perform the steps described herein (e.g., steps described herein with respect to flowcharts). In other embodiments, the device 601 may be configured to perform the steps described herein without the need for code; that is, for example, the 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.

[0095]

[0101] Implementation

[0102] 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, 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.

[0096]

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

[0097]

[0104] 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.

[0098]

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

[0099]

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

[0100]

[0107] B4. The method of embodiment B2, wherein the update request is an HTTP PUT request with a resource identifier (eg, a URI) that has a restriction identifier.

[0101]

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

[0102]

[0109] 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.

[0103]

[0110] C1. An apparatus (601) adapted to send (s406) a request for information (252) to a depository function (e.g., UDR 204), where the UDR 204 is configured to send a response (254) in response to the request, and to 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.

[0104]

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

[0105]

[0112] 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.

[0106]

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

[0107]

[0114] The following describes the changes to TS 29.519 proposed in this specification.

[0115] First change

[0116] 5.2.6.2 Resource definition

[0117] Resource URI:{apiRoot} / nudr-dr / v1 / policy-data / {ueId} / sm-data / {usageMonId}

[0108]

[0118] This resource MUST support the resource URI variables defined in the table below. [Table 5]

[0109]

[0119] Second Change

[0120] 5.2.6.3.3GET

[0121] This method MUST support the URI query parameters specified in the table below. [Table 6]

[0110]

[0122] While various embodiments have been described herein, it should be understood that they have been presented for illustrative purposes only, and not for limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the exemplary embodiments described above. Moreover, unless otherwise stated herein or clearly contradicted by context, the present disclosure encompasses all possible combinations of the elements described above.

[0111]

[0123] Moreover, while the procedures described above and illustrated in the figures are shown as a series of steps, this is for illustrative purposes only. It is therefore contemplated that steps may be added, steps may be omitted, the order of steps may be rearranged, and steps may be performed in parallel. Also, the phrase "receive from" should be interpreted as encompassing "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 a message sent by the second entity and the third entity forwards the message to the first entity.

[0112]

[0124] Abbreviation

[0125] AF Application Features

[0126] AMBR Aggregate Maximum Bitrate

[0127] APN Access Point Name

[0128] ARP Allocation and Retention Priority

[0129] ASA Abort Session Answer

[0130] ASR Abort Session Request

[0131] CHF billing function

[0132] DNN Data Network Name

[0133] HTTP Hypertext Transfer Protocol

[0134] IP-CAN IP-connectable access network

[0135] GPSI General Public Subscriber Identifier

[0136] H-PCF Home Policy Control Function

[0137] PCC Policy and Charging Control

[0138] PCF Policy Control Function

[0139] PCRF Policy and Charging Rules Function

[0140] PDU Protocol Data Unit

[0141] PEI Permanent Equipment Identifier

[0142] PGW Packet Data Network Gateway

[0143] RAT Radio Access Technology

[0144] SM Short Message(?)

[0145] SMF Session Management Facility

[0146] SPR Subscription Profile Repository

[0147] STA Session Termination Response

[0148] STR Session Termination Request

[0149] SUPI Subscription Permanent Identifier

[0150] S-NSSAI Single Network Slice Selection Assistance Information

[0151] UDR Unified Data Repository

[0152] UP User Plane

[0153] UPF User Plane Function

[0154] V-PCF Destination policy control function

[0155] 5QI 5G Quality of Service (QoS) Identifier

Claims

1. 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.

2. 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.

3. 3. 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 notification to the policy function when a change occurs to the UsageMonData instance associated with the UsageMonDataLimit instance.

4. 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. 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.

6. 6. The method of claim 1, 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. 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 the maximum allowable traffic volume, or a reset period used to indicate the time when the allowable usage should be reset.

8. 8. The method of claim 1 , wherein the usageMonDataLimit instance further comprises a data coverage indicating a combination of S-NSSAI and DNN to which the usageMonDataLimit instance applies.

9. 9. The method of claim 1, wherein the usageMonData instance: a usage monitor level (umLevel) instance indicating whether said usageMonData instance applies at the PDU session level or at the service level; or 11. A method comprising: at least one of an allowed usage value, said allowed usage value indicating a remaining allowed amount of traffic, and / or said allowed usage value indicating an amount of time remaining.

10. 10. The method of claim 7, wherein the usageMonData instance further comprises information indicating a time to reset allowed usage to the usage limit threshold.

11. 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.

12. The method of claim 11, further comprising the depository function receiving (s506) an update request (304) sent by the policy function.

13. 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.

14. The method according to any one of claims 11 to 13, further comprising the depository function receiving (s508) an unsubscription request (306) from the policy function.

15. 15. 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. 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 the maximum allowable traffic volume, or a reset period indicating a time to reset the allowed usage.

17. 17. The method of claim 11, wherein the usageMonDataLimit instance further comprises a data coverage indicating a combination of S-NSSAI and DNN to which the usageMonDataLimit instance applies.

18. 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 the PDU session level or at the service level; or 11. A method comprising: at least one of an allowed usage value, said allowed usage value indicating a remaining allowed amount of traffic, and / or said allowed usage value indicating an amount of time remaining.

19. 19. The method of any one of claims 17 to 18, wherein the usageMonData instance further comprises information indicating a time to reset allowed usage to the usage limit threshold.

20. A computer program (643) having instructions (644) which, when executed by a processing circuit (602) of an apparatus (600), causes said apparatus (600) to perform the method of any one of claims 1 to 19.

21. 21. 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).

22. 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.

23. A policy function apparatus according to claim 22, further adapted to carry out a method according to any one of claims 2 to 10.

24. 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.

25. 25. A depository functional apparatus according to claim 24, further adapted to carry out a method according to any one of claims 12 to 19.

Images