Patent Description:
BDT policy handling is a functionality that allows an Application Function (AF) to transmit/receive a certain volume of background data traffic per UE or for a number of UEs under some requirements, such as a time window for transfer, specific network conditions, and optionally a network area where the transfer occurs. A Policy Control Function (PCF) can derive a BDT policy that adapts to those requirements. The BDT policy typically may define which QoS and charging control policy are employed within a specific time window for a UE. 3GPP has defined BDT policy handling in EPC and has evolved this functionality into <NUM> networks. See 3GPP TS <NUM><NUM>.

In IoT and V2X scenarios, a UE is usually moving during a BDT process. For example, truck floats need to report petrol consumption in a driving state, or drones need to report traffic information in flying. Thus, it is desirable to develop a solution available for these scenarios.

<NPL>) discloses that, for a negotiation for future background data transfer, network area information is added into a background transfer policy profile.

One of the objects is to provide methods and apparatus for handling Background Data Transfer (BDT) for a User Equipment (UE), which allows an optimal usage of network resources and an accurate charging model applied to BDT traffic.

Aspects of the invention are set out in the independent claims appended hereto.

One or more embodiments of the present invention at least have the following advantages:.

The foregoing and other objects, features, and advantages would be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings in which:.

As used herein, the term "processor" refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.

It will be further understood that the terms "comprises" "comprising," "includes" and/or "including" when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Also, use of ordinal terms such as "first," "second," "third," etc., in the claims to modify a claim element does not by itself connote any priority, precedence, or order of one claim element over another or the temporal order in which acts of a method are performed, but are used merely as labels to distinguish one claim element having a certain name from another element having a same name (but for use of the ordinal term) to distinguish the claim elements.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood.

As an illustrative example, in a typical <NUM> System architecture, a node for Application Function (AF) and a node for Policy Control Function (PCF) may negotiate BDT policies for one or more UEs. The node for AF may initiate a BDT policy negotiation procedure by transmitting to the node for PCF a BDT policy request. As a response, the node for PCF derives or determines the BDT policies and returns them to the node for AF. See 3GPP TS <NUM><NUM>.

Typically, a UE trajectory may be represented in form of a plurality of sections or segments, which one UE will sequentially travel or is expected to sequentially travel. In one or more embodiments of the present invention, a UE trajectory is introduced when determining or deriving a BDT policy for a UE. Specifically, a BDT policy can be tailored for each of the sections, i.e., the BDT policy is section-basis. For example, the BDT policy can designate or define a time period and a network area for BDT which are associated with the corresponding section as well as QoS/charging conditions, e.g., charging rate and maximum aggregated bitrate applicable to the time period or the network area as designated. Since the BDT policy is UE trajectory-relevant, it allows an optimal usage of network resources and an accurate charging model applied to BDT traffic as compared to the prior art where the "temporal granularity" for the BDT policy is larger.

It shall be noted that besides the UE trajectory, one or more other aspects can be under consideration individually or in combination when deriving a BDT policy. The examples of these additional aspects include but are not limited to network policy, existing transfer policies, network area information, load status estimation and level information in a S-NSSAI.

The UE trajectory may be either one that one UE will follow during BDT process or a predicted or expected version. In 3GPP TS <NUM> v16. <NUM>, Mobility Pattern (MP) is used for characterizing and optimizing UE mobility. Thus, the statistics of the UE mobility can reflect a historical or expected UE moving trajectory. According to 3GPP TS <NUM>, the statistics of the UE mobility can be provided by a node for Network Data Analytics Function (NWDAF).

In one or more embodiments of the present invention, to obtain a BDT policy that is UE trajectory-relevant, the node for AF initiates a BDT policy negotiation procedure by transmitting a BDT policy request explicitly or impliedly indicating or asserting this intention.

In one or more embodiments of the present invention, the BDT policy request at least includes an Application Service Provider (ASP) identifier, volume of data to be transferred for a UE, desired time window for data transfer, and a UE trajectory if available. As an example, the UE trajectory may be in form of a list of Tracking Arears (TAs), NG-RAN nodes or cells with trajectory information, e.g., sequencing and timing of the TAs, which is different from a plain list of TAs.

Note that the inclusion of the UE trajectory in the request can be regarded as an implied indication that the BDT is UE trajectory-relevant, and thus an explicit indication may be omitted. Sometimes, however, the UE trajectory is unavailable at the node for AF. In this case, an explicit indication shall be included in the request instead of the UE trajectory.

Optionally, the request may include network area information, which defines either a geographical area (e.g. a civic address or shapes), or an area of interest that includes a plain list of TAs, NG-RAN nodes and/or cell identifiers. With the optional network area information, a common BDT policy can be derived even if the node for PCF lacks capability of handling UE-trajectory BDT policy.

In response to the request from the node for AF, the node for PCF may derive a plurality of BDT policy groups, each of which is applied to one corresponding section of the UE trajectory. As an illustrative example, the corresponding section is associated with a specified network area. The node for PCF may transmit the BDT policy groups as derived, along with a unique reference identifier associated with or allocated to the UE trajectory of the UE, to the node for AF.

In one or more embodiments, to derive a BDT policy for each of the sections of the UE trajectory, the node for PCF may firstly retrieve all existing transfer policies stored in a node for User Data Repository (UDR). Afterwards, the node for PCF may derive or determine one or more available BDT policies from the existing transfer policies for the corresponding section. The determination may be made based on one or more aspects individually or in combination. These aspects include but are not limited to network policy, existing transfer policies, network area information, load status estimation and level information in a S-NSSAI. The node for PCF may be configured to map an ASP identifier into a target DNN and slicing information (i.e. S-NSSAI).

In one ore more embodiments of the present invention, one available BDT policy may consist of a recommended BDT time window for the corresponding section of the UE trajectory, a reference to a charging rate for the recommended BDT time window, and optionally a maximum aggregated bitrate indicating that the charging level according to the referenced charging rate is only applicable to the aggregated traffic of all involved UEs that stay below the referenced charging rate.

In one or more embodiments of the present invention, preferably, the BDT policy groups can be listed in a sequence, the order of which corresponds to that of the sections, whereby impliedly describing the sequence of the PDT policy groups to be applied. Note that each of the BDT policy groups may include either a single available BDT policy or a plurality of available BDT policies. For the case of the single available BDT policy, it is regarded as a default or an applied BDT policy which will be applied when BDT is carried out with a specified time window for the corresponding section. In case where more than one available BDT policies are included in one BDT policy group, the node for AF may select one of the available BDT policies as an applied BDT policy and return the selection to the node for PCF, which in turn, stores the applied BDT policy along with the reference identifier allocated to the UE trajectory of the UE in the node for UDR.

In case where the node for AF fails to provide the UE trajectory in the BDT policy request, the node for PCF may determine the UE trajectory locally or obtain an expected or analytic UE trajectory from other sources, e.g., a node for NWDAF, as the UE trajectory. For example, the node for NWDAF may use the network area information as a hint to filter out from all of the possible UE trajectories an expected one.

Alternatively, in case the node for PCF supports UE trajectory-relevant BDT policy, it may return to the node for AF both of UE trajectory-relevant BDT policies and UE trajectory-irrelevant BDT policies. Optionally, the node for PCF may return a common BDT policy derived based on the network area information if the node for PCF lacks capability of handling UE-trajectory BDT policy.

In one or more embodiments of the present invention, during a BDT procedure for a UE, the node for AF may transmit, to the node for PCF, AF session information along with a reference identifier allocated to a UE trajectory of the UE. Based on the reference identifier, the node for PCF may retrieve from the UDR a sequence of applied BDT policies, each of which will be sequentially applied to the respective section, and derive Policy and Charging Control (PCC) rules according to the applied BDT policies. Afterwards, the node for PCF may monitor the movement of the UE and carry out each of the applied BDT policies when the UE moves into the respective section of the UE trajectory.

Note that sometimes, different nodes participate in negotiating the BDT policies with a node for PCF and transferring background data in cooperation with the node for PCF. In this case, the node for AF participating in the BDT may transmit the unique reference identifier associated with the UE trajectory of the UE, based on which the node for PCF may retrieve from the UDR a sequence of applied BDT policies.

For xBDT scenarios (ongoing work in SA2 which addresses the UE initiated massive traffic, e.g. for uploading collected 3D map data from a car to an application server), the UE trajectory-relevant policy is still applicable. In particular, for example, a URSP policy may include time interval and geographical information and share a common BDT reference ID with a BDT policy. Thus, the URSP policy may be one that is UE trajectory-relevant or section-basis.

For UE controlled xBDT, background data will be transmitted to the UE as part of UE policy including, e.g., the time interval and geographical location at which the UE policy applies. The UE will be responsible for handling MO traffic in accordance with the time interval and location condition in the UE policy.

For network controlled xBDT, the Npcf_UEPolicyControl service may be in charge of updating the UE with the applicable UE Policy per section, based on the time interval and location conditions defined for the corresponding section of the UE trajectory. Moreover, the network (PCF - Npcf_SMPolicyControl) may be responsible for controlling the UE PDU session's QoS/Charging according to the negotiated BDT policy on the section-basis.

A flowchart of a method <NUM> for handling BDT for a UE according to one embodiment of the present invention is shown in <FIG>.

The flowchart as shown in <FIG> comprises the following steps performed at AF side:.

<FIG> is a block diagram illustrating an apparatus for handling BDT for a UE according to another embodiment of the present invention.

With reference to <FIG>, an apparatus <NUM> comprises a storage device <NUM> and a processor <NUM> coupled to the storage device <NUM>. The storage device <NUM> is configured to store a computer program <NUM> comprising computer instructions. The processor <NUM> is configured to execute the computer instructions to perform some or all of the method steps as shown in <FIG>. In this embodiment, the apparatus <NUM> may be a node for AF.

The flowchart as shown in <FIG> comprises the following steps performed at PCF side:
Step <NUM>: The node for PCF receives, from a node for AF e.g., via a node for Network Exposure Function (NEF), a BDT policy request indicating the BDT for a UE is UE trajectory-relevant.

In an illustrative example, the request may include an Application Service Provider (ASP) identifier, volume of data to be transferred for the UE, desired time window for data transfer, an indicator indicating the BDT is UE trajectory-relevant, and UE trajectory of the UE if available.

Step <NUM>: The node for PCF determines whether it is capable of handling UE-trajectory BDT policy. If having such capability, the flowchart proceeds to step <NUM>; otherwise, the flowchart proceeds to step <NUM>.

Step <NUM>: The node for PCF determines whether the BDT policy request includes the UE trajectory. If it is the case, the flowchart proceeds to step <NUM>; otherwise, the flowchart proceeds to step <NUM>.

Step <NUM>: The node for PCF derives one or more common BDT policies without considering the UE trajectory. For example, the common BDT policies may rely on the following aspects individually or in combination: network policy, level information in a S-NSSAI and load status estimation for the required time window, network area information, and existing transfer policies. After step <NUM>, the flowchart proceeds to step <NUM>.

Step <NUM>: The node for PCF derive a plurality of BDT policy groups, each of which is applied to one corresponding section of the UE trajectory. For example, to derive a BDT policy for each of the sections of the UE trajectory, the node for PCF may derive or determine one or more available BDT policies in the respective BDT policy group. The determination may be made based on, e.g., existing transfer policies, network area information, load status estimation and level information in a S-NSSAI. After step <NUM>, the flowchart proceeds to step <NUM>.

Step <NUM>: The node for PCF may request the node for NWDAF to provide an expected UE trajectory. After step <NUM>, the flowchart proceeds to step <NUM> where the expected UE trajectory is used for deriving available BDT policies.

Step <NUM>: The node for PCF transmits to the node for AF, e.g. via the NEF, one or more common BDT policies as derived at step <NUM> or a plurality policy groups as derived at step <NUM>. After step <NUM>, the flowchart proceeds to step <NUM>.

Step <NUM>: In this embodiment, for those BDT policy group including more than one available BDT policies, the node for AF selects one as an applied BDT policy for the respective BDT policy group. Likewise, for multiple common BDT policies, the node for AF selects one as an applied BDT policy. At this step, the node for PCF receives from the node for AF the applied BDT policies as selected. After step <NUM>, the flowchart proceeds to step <NUM>.

Step: <NUM>: The node for PCF stores the common BDT policy or the applied BDT policies of all of the BDT policy groups at a node for User Data Repository (UDR).

With reference to <FIG>, an apparatus <NUM> comprises a storage device <NUM> and a processor <NUM> coupled to the storage device <NUM>. The storage device <NUM> is configured to store a computer program <NUM> comprising computer instructions. The processor <NUM> is configured to execute the computer instructions to perform some or all of the method steps as shown in <FIG>. In this embodiment, the apparatus <NUM> may be a node for PCF.

As described above, a node for Application Function (AF) and a node for Policy Control Function (PCF) may negotiate BDT policies for one or more UEs. In an illustrative example, the negotiation can be achieved by modifying a negotiation procedure for BDT as defined in 3GPP TS <NUM><NUM>.

<FIG> schematically illustrates a modified negotiation procedure according to another embodiment of the present invention.

As shown in <FIG>, the procedure comprises the following steps:
Step <NUM>: The AF invokes a Nnef_BDTPNegotiation_Create service operation by sending an Nnef_BDTPNegotiation_Create request to the resource "BDT Subscription" to get BDT policies. The request shall contain an ASP identifier, the volume of data to be transferred per UE, the expected amount of UEs, the desired time window and optionally, network area information either as a geographical area (e.g. a civic address or shapes), or an area of interest that includes a list of TAs and/or list of NG-RAN nodes and/or a list of cell identifiers. When the AF provides a geographical area, then the NEF maps it based on local configuration into a short list of TAs and/or NG-RAN nodes and/or cells identifiers that is provided to the (H-)PCF. When the AF requires UE trajectory-relevant BDT policies, the AF will indicate this intention in the Nnef_BDTPNegotiation Create request. If available, the AF will also provide the UE trajectory in the request.

Furthermore, since the AF does not know if the PCF supports the handling of UE trajectory, preferably, it may also provide the network area information.

Step <NUM>: Upon receipt of the Nnef_BDTPNegotiation_Create request from the AF, the NEF invokes the Npcf_BDTPolicyControl_Create service operation with the (H-)PCF by sending an Npcf_BDTPolicyControl_Create request to the resource "BDT policies". The request operation includes the ASP identifier, the volume of data to be transferred per UE, the expected number of UEs, the desired time window, and optionally the network area information (list of TAs and/or NG-RAN nodes and/or cells identifiers). If the Nnef_BDTPNegotiation_Create request received at the NEF includes an indicator that BDT policies are UE trajectory-relevant and the UE trajectory, the NEF will transmit the UE trajectory to the (H-)PCF.

Step <NUM>: The (H-) PCF may invoke the Nudr_DataRepository_Query service operation by sending an Nudr_DataRepository_Query request to the resource "BdtData", to request from the UDR all stored transfer policies.

Step <NUM>: The UDR sends an HTTP "<NUM> OK" response to the (H-) PCF.

Note that in case only one PCF is deployed in the network, transfer policies can be locally stored in the PCF and the interaction with the UDR is not required.

Step <NUM>: The (H-) PCF determines one or more BDT policies based on the information received from the NEF and other available information (e.g. network policy, existing transfer policies, network area information and load status estimation for the desired time window). If the UE trajectory was received and the (H-)PCF supports this functionality, the (H-)PCF may derive BDT policies per trajectory section having respective QoS and charging demands. That is, the (H-)PCF may derive a plurality of BDT policy groups for the UE trajectory, each of which is applicable to one corresponding section. Sometimes, the AF may have no knowledge of the UE trajectory. In this situation, if the AF indicated that the BDT policies could be UE trajectory-relevant and the PCF supports this functionality, the (H-)PCF may send the ASP identifier and the network area information if available to an NWDAF, which derives an expected or analytic UE trajectory and returns it to the (H-)PCF. Therefore, the (H-)PCF determines the BDT policies for the sections of the expected or analytic UE trajectory. Furthermore, if the (H-)PCF does not support the functionality, current procedures as defined in 3GPP TS are applied.

Step <NUM>: The (H-) PCF invokes an Npcf_BDTPolicyControl Create service operation by transmitting the BDT policy groups as derived along with a BDT Reference ID associated with the UE trajectory of the UE. If more than one available BDT policies is included in one BDT policy group, an indicator may be accompanied with the BDT policy group, indicating multiple transfer policies for the corresponding section. Moreover, the PCF may transmit UE trajectory-irrelevant BDT policies.

Step <NUM>: The NEF sends an Nnef_BDPNegotiation_Create response to forward the received BDT policy Groups to the AF.

Note that if more than one available BDT policies are derived for one or more sections of the UE trajectory, the AF will select one applied BDT policy for the corresponding section. In this situation, steps <NUM>-<NUM> are executed. Otherwise, the flow proceeds to step <NUM>.

Step <NUM>: The AF invokes the Nnef_BDTPNegotiation_Update service operation by sending an HTTP PATCH request to the resource "Individual BDT Subscription" to provide the NEF with the applied BDT policy as selected.

Step <NUM>: The NEF invokes the Npcf_DTPolicyControl_Update service operation by sending an HTTP PATCH request to the resource "Individual BDT policy" to provide the (H-)-PCF with the selected applied BDT policies.

Step <NUM>: The (H-) PCF sends an HTTP PATCH response message to the NEF.

Step <NUM>: The NEF sends an HTTP PATCH response message to the AF.

Step <NUM>: If the applied BDT polices are not locally stored at the (H-)PCF, the (H-)PCF invokes the Nudr_DataRepository_Update service operation by sending an HTTP PUT request to the resource "IndividualBdtData" to store the applied BDT polices along with the associated BDT reference ID, the volume of data per UE, the expected number of UEs and the corresponding network area information if available in the UDR.

Step <NUM>: The UDR sends an HTTP "<NUM> Created" response to the (H-)PCF.

AF Session Establishment may trigger PCF-initiated SM Policy Association Modification procedure as defined in 3GPP TS <NUM>.

<FIG> schematically illustrates a PCF-initiated SM Policy Association Modification procedure.

As shown in <FIG>, the procedure comprises the following steps:.

Additionally, if the AF provided a Background Data Transfer Reference ID in step <NUM> or step 1a and the corresponding transfer policy is not locally stored in the PCF, the PCF sends the HTTP GET request to the "BdtData" resource. The UDR sends an HTTP "<NUM> OK" response to the PCF with the Background Data Transfer policy.

Step <NUM>: The PCF identifies the affected established PDU Session (s) using the information previously received from the SMF and the Service Information received from the AF.

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

Step 6a: The PCF sends a Diameter AAA to the AF.

Step <NUM>: The AF may invoke the Npcf_Policy Authorization_Subscribe service operation by sending the HTTP PUT request to the "Events Subscription" resource to subscribe to events in the PCF. The request includes the events that subscribes and a Notification URI to indicate to the PCF where to send the notification of the subscribed events.

Step <NUM>: The PCF interacts with SMF. In one embodiment of the present invention, this operation may be performed according to an interactions procedure between SMF, PCF and CHF for PCF-initiated SM Policy Association Modification procedure as shown in <FIG>.

Claim 1:
A method for handling Background Data Transfer, BDT, for a User Equipment, UE, comprising:
- a) transmitting (<NUM>), from a node for Application Function, AF, to a node for Policy Control Function, PCF, a BDT policy request indicating the BDT is UE trajectory-relevant; and
- b) at the node for AF, receiving (<NUM>) from the node for PCF, a message comprising a plurality of BDT policy groups, each of which is associated with a corresponding section of a predicted trajectory.