Usage monitoring 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] TECHNICAL FIELD

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

[0002]

[0002] Usage monitoring allows network operators to monitor subscriber data. Usage amount 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) so that a traffic handling network function (e.g., a 4G PGW / UP or a 5G SMF / UPF) can monitor traffic with respect to that monitoring key.

[0004]

[0004] Monitoring keys are assigned by a policy function. If monitoring is applied at the service level, the monitoring key is provided as part of the policy rules (e.g., PCC rules), and if monitoring is applied to a session (e.g., IP-CAN / PDU session), the monitoring key is provided as part of the session information. 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] 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 a PCF and a Unified Data Repository (UDR). TS 29.519 defines specific resources 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 uses the remaining messenger To store the usage, a usage monitor resource can be created. 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] How does PCF get usageMonId and what does usageMonId mean? Usage amount It is not specified how this relates to the information in the limits (UsageMonDataLimit data type) or the monitoring data (UsageMonData).

[0010]

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

[0012]

[0012] 1) The target range of the monitoring key value is set for each S-NSSAI / DNN pair. However, if the target range of the monitoring key value is set for each S-NSSAI / DNN pair, Usage amount of Cumulative Additionally, the following changes to the current specification would be necessary: ​​individual resources of UsageMonitoringInformation correspond to different limits. Cumulative As a result, UsageMonData needs to be updated to include S-NSSAI / DNN information, and Cumulative To maintain greater control during device updates, the PATCH method should be used instead of PUT.

[0013]

[0013] 2) The scope of the monitoring key value is set 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 if the restrictions are different. If this is implemented, the current method of defining the monitoring key will be restricted, and the cumulative messenger Dosage monitoring in SMF messengerThe following impacts will need to be considered: each resource in UsageMonitoringInformation corresponds to a certain limit. Cumulative usage In other words, DNN / S-NSSAI information is UsageMonitoringInformation resource This is because the DNN / S-NSSAI information is taken into account in the restriction definition of the Sm-Data resource. The query parameters in S-NSSAI / DNN can be removed.

[0014] 3) The value of the monitoring key is unique. Value Scoping by deployment, so that each resource in UsageMonitoringInformation corresponds to the latest update of the S-NSSAI / DNN pair. Cumulative usage In other words, DNN / S-NSSAI information is UsageMonitoringInformation resource This is because the DNN / S-NSSAI information is taken into account in the restriction definition of Sm-Data resources that already contain monitoring keys. The S-NSSAI / DNN query parameters can be removed and the individual resources in UsageMonitoringInformation will not contain the exact restriction information, but the residual value at the time of the last PDU session update.

[0015]

[0015] All of these possible approaches are messenger The use of monitoring keys in the context of dose monitoring is performed in a user database. Cumulative This limits how monitoring keys are used today, separating them from the encryption method.

[0016]

[0016] Thus, the present disclosure provides a "usageMonId" resource identifier (e.g., URI) variable that messengerWe propose to use an identifier to identify the dosage limit. This identifier may be called the "Accumulator / Limit Identifier" or (abbreviated as "limitId"). Each resource in UsageMonitoringInformation corresponds to a given limit identified by the limit identifier. cumulative usage It represents dosage information. Therefore, there is no restriction on the definition of the monitoring key value. This method requires the inclusion of limitId in the UsageMonDataLimit and UsageMonData data types. The advantage of the proposed method is that it provides the most flexibility for the current scope of monitoring keys. The proposed method also allows for the use of UDRs. Cumulative It allows the decoupling of the monitoring key usage from the encryption method, and furthermore, Cumulative It allows for flexible modeling of the multiplication method. There are no restrictions on the definition of the supervision key, so for each different combination of DNN and S-NSSAI, Cumulative This allows for a variety of business models for integrating resources, and has the added benefit of not affecting the way usage is monitored.

[0017]

[0017] Accordingly, 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 the 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]

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

[0022] In some embodiments, the UsageMonDataLimit instance further includes a usage monitor level instance indicating whether the UsageMonDataLimit instance is applied 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, and a maximum allowable traffic volume. messenger Dose-limiting threshold, or tolerance messenger a reset period, which is used to indicate the time when the dose needs to be reset.

[0023] In some embodiments, the UsageMonDataLimit instance is a data limit indicating the combination of S-NSSAI and DNN to which the UsageMonDataLimit instance applies. Data scope It further has:

[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, which indicates the remaining allowed traffic volume and / or the amount of time remaining.

[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 a restriction identifier, or the update request is an HTTP PATCH request with a resource identification having a restriction identifier. Child This is an HTTP PUT request with

[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 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 volume 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 allowable usage value, which indicates the remaining allowable traffic volume and / or the length of time remaining.

[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 processing circuitry 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, where the usageMonData instance also has 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, where the usageMonData instance also has the limit identifier. [Brief explanation 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] Figure 1 shows an example of a resource structure. [Figure 2]

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

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

[0040] FIG. 4 is a flowchart illustrating a procedure according to one embodiment. [Figure 5]

[0041] FIG. 5 is a flowchart 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 INVENTION

[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 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. [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 specifying 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 TS 29.519, table 5.4.2.7-1, 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, section 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 indicating the time at which the allowed usage should be reset 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] Section 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}." Section 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] Figure 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 interactions 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).

[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 the 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 Section 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, 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 also 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 DNN. If the PCF 202 does not have subscription data for the SUPI and 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 using a GET request to the ... / sm-data resource URI.

[0053]

[0059] Each UsageMonDataLimit instance contains a "limitId" attribute that identifies the name of the limit (e.g., "limitId": "Facebook-limit"), along with the 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). where "UsageMonId" is the "limitId" contained in the received UsageMonDataLimit instance. Note that the PCF 202 may subscribe to receive change notifications for 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 PCF202 determines that the policy decision depends on the state of policy counters available in the CHF206 and such reporting has not been established for the subscriber, the PCF202 initiates an Initial Spending Limit Report Retrieval as defined in 3GPP TS 29.594 V15.1.0, section 5.3.2. If the PCF202 determines that policy counter state reporting has already been established for the subscriber and further policy counter state is required, the PCF202 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 based on 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 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.

[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: SMF201 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, it 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 access network information in step 1 and the AF 301 previously requested the PCF 202 to report 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 terminate 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 relate to the "Rx" case, i.e., when 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 end of the SM policy association, the PCF 202 updates the remaining usage in the UDR for applicable limits. The PCF 202 can send a PATCH request to the ... / sm-data resource URI containing 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, the PCF 202 can send a PUT request to the ... / {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 terminate 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 includes a PolicyDataSubscription data structure with an updated list of "monitoredResourceUris", which will no longer include the aforementioned ... / {usageMonId} resource URI. Alternatively, the PCF 202 may terminate 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 so that the policy function receives the request (directly or indirectly) from the management function.

[0081]

[0087] Step s404 includes the policy function determining whether the policy function 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.

[0082]

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

[0083]

[0089] Step s408 includes the policy function receiving a response 254 to the request. The response is 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 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 comprises 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., script and / or compiled code), the apparatus 601 may execute the PCF / UDR software. Accordingly, 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 an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), 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 to enable 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.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), etc. In some embodiments, CRI 644 of computer program 643, when executed by PC 602, causes CRI to operate device 60. 1 The PC 602 may be configured to cause the PC 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 consist 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, where the response comprises 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.

[0096]

[0103] A2. The method of embodiment A1, wherein before sending the request (252), the policy function receives the request (251) sent by the management function (e.g., SMF). (s402) The method further comprises the policy function determining (s404) whether the policy function needs to fetch information from the 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) having a restriction identifier.

[0101]

[0108] B5. The method of any one of embodiments B1 through 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. A device (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 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 the depository function after receiving the request (251) sent by the management function before sending the request (252).

[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 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, unless otherwise stated herein or otherwise clearly contradicted by context, the present disclosure encompasses all possible combinations of the elements described above in all possible variations.

[0111]

[0123] Furthermore, while the procedures described above and illustrated in the figures are shown as a series of steps, this is for illustrative purposes only. Accordingly, it is 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 the second entity sends the message and the third entity receives it and 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 Universal 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); The policy function (202) receives (s408) a response (254) to the request; The response (254) a usageMonDataLimit instance having a limit identifier, the limit identifier identifying a usage monitoring control instance; a usageMonData instance corresponding to the usageMonDataLimit instance, wherein the usageMonData instance also has the limit identifier.

2. 10. The method of claim 1 further comprising: Before sending the request (252), the policy function (202) receives (s402) a request (251) from the management function (201); In response to the request (251), the policy function (202) determines (s404) 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, wherein the update request (304) is an HTTP PUT request with a resource identifier that has the 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: a usage monitor level instance indicating whether said 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 that indicates the maximum amount of traffic allowed, or and a reset period used to indicate when the allowable usage should be reset.

8. 8. The method of claim 7, The usageMonDataLimit instance further has a data coverage indicating the S-NSSAI and DNN combination to which the usageMonDataLimit instance applies; and / or The usageMonData instance further comprises: a usage monitor level (umLevel) instance indicating whether said usageMonData instance applies at the PDU session level or the service level; or 10. A method comprising: at least one 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.

9. 9. The method of claim 7 or 8, wherein the usageMonData instance further comprises information indicating a time at which to reset the allowed usage to the usage limit threshold.

10. 1. A method (500) comprising: The depository function (204) receives (s502) a request for information (252) from the policy function (202); the depository function (204) sending (s504) a response (254) in response to the request from the policy function (202); The response (254) a usageMonDataLimit instance having a limit identifier, the limit identifier identifying a usage monitoring control instance; a usageMonData instance corresponding to the usageMonDataLimit instance, wherein the usageMonData instance also has the limit identifier.

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

12. 12. The method of claim 11, The update request (304) is an HTTP PATCH request with a usageMonData instance that has the restriction identifier, or The method, wherein the update request (304) is an HTTP PUT request with a resource identifier that has the restriction identifier.

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

14. 14. The method of claim 13, wherein the unsubscribe request is an HTTP PUT request having a body with a resource identifier that has the restriction identifier.

15. 15. The method of any one of claims 10 to 14, wherein the usageMonDataLimit instance: 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 that indicates the maximum amount of traffic allowed, or and a reset period used to indicate when the allowable usage should be reset.

16. 16. The method of claim 15, wherein the usageMonDataLimit instance further comprises a data coverage indicating a combination of S-NSSAI and DNN to which the usageMonDataLimit instance applies; and / or 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 10. A method comprising: at least one 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.

17. 17. The method of claim 15 or 16, wherein the usageMonData instance further comprises information indicating a time at which to reset the allowed usage to the usage limit threshold.

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

19. A policy function device (601), Sending a request for information (252) to the depository function (204); adapted to receive a response (254) to said request; The response (254) includes a usageMonDataLimit instance having a limit identifier, the limit identifier identifying a usage monitoring control instance, and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier.

20. 20. A policy function apparatus according to claim 19, further adapted to carry out the method according to any one of claims 2 to 9.

21. A depository function 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) includes a usageMonDataLimit instance having a limit identifier, the limit identifier identifying a usage monitoring control instance, and a usageMonData instance corresponding to the usageMonDataLimit instance, the usageMonData instance also having the limit identifier.

22. 22. A depository function apparatus according to claim 21, further adapted to carry out a method according to any one of claims 10 to 17.

Images