Optimized charging trigger handling using rules on triggers

Abstract

There is provided a method (400) for configuring and handling charging triggers in a Network Function (NF), the method being performed by the NF and including: obtaining (S410) data indicative of a charging trigger, wherein the charging trigger defines a trigger condition for issuing a charging event to a Charging Function (CHF); obtaining (S412) data indicative of one or more additional conditions associated with the charging trigger, and issuing (S414) the charging event towards the CHF in response to confirming a fulfillment of both the trigger condition and at least one of the one or more additional conditions. A corresponding method performed in a CHF, as well as NF and CHF entities, computer programs and computer program products are also provided.

Description

OPTIMIZED CHARGING TRIGGER HANDLING USING RULES ON TRIGGERSTechnical field[oooi] The present disclosure relates to the field of cellular networks. In particular, the present disclosure relates to configuring and handling of charging triggers in such networks.Background

[0002] In for example fifth generation (5G) telecommunication architectures, charging triggers (as described in e.g. 3GPP TS 32.290 / 291) are used to report chargeable events from a Network Function (NF) to a (Converged) Charging Function (CHF). Which triggers to use in the NF maybe configured by e.g. the CHF and communicated to the NF as part of a charging data response sent in response to the CHF receiving a charging data request from the NF. The charging triggers may for example be set on a per-charging session basis, and defined as immediate / deferred, enabled / disabled, and / or with some additional values for limits and / or thresholds.

[0003] The conditions based on which a charging event should be issued to the CHF are e.g. provided as part of the charging data response, and a date / time from which a specific trigger condition should be enabled is decided by (i.e., aligned with) the response time from the CHF. Other (default) conditions maybe configured directly in the NF, and will be enabled from when such a configuration was performed. The conditions for when a particular charging event is to be issued may include e.g. that a “user location has changed”, that a “time limit has been reached”, or any other condition defined in 3GPP TS 32.291 table 6.2.5.3.5-1 (as provided by the attribute “triggerType” of the type “Trigger”).

[0004] Charging triggers as used in e.g. contemporary 5G architectures may further allow to define charging events that are applicable only in certain scenarios. For example, in case there is a desire to apply a particular charging rate when a subscriber is in a particular area, the trigger type USER_LOCATION_CHANGE may be activated, such that a charging event is issued towards the CHF each time the subscriber changes location, and the CHF may receive such events and check whether the current location corresponds to that for which the particular charging rate shouldapply. As another example, if there is a desire to apply a particular charging rate when the subscriber is using a particular Radio Access Technology (RAT) type, the trigger type RAT_CHANGE may be enabled such that the CHF may receive a charging event each time the subscriber changes the RAT type.

[0005] The present disclosure seeks to develop the available charging trigger functionality and to mitigate one or more shortcomings thereof.Summary

[0006] Trigger conditions are defined to generate chargeable events from the NF (often in form of / including a Charging Trigger Function, CTF) to the CHF when the trigger conditions are met. Consequently, charging triggers are a driving factor for things like rating and charging in the CHF. At the same time, when a charging trigger is enabled, the NF / CTF will start evaluating the trigger and start generating / issuing chargeable events towards the CHF.

[0007] However, as the inventors have realized, there may exist multiple scenarios in which the contemporary charging triggers generates unnecessary data traffic and resulting load on the telecommunication system. For example, in a scenario when there is a need to apply a particular, special charging ratio only for a particular subscriber location, the contemporary charging triggers will cause charging events to be issued every time the location of the subscriber changes, independently of whether the change is to / from the particular location or not. Likewise, contemporary triggers are not capable of issuing a charging event only when a particular RAT type is used, but will instead issue such charging events each time the RAT type changes, independent of whether the change is to / from the particular RAT type or not. As realized by the inventors, there is therefore a need for more flexible charging triggers in present and future telecommunication architectures.

[0008] To at least partially satisfy such a need, the present disclosure therefore provides an improved method for configuring and handling charging triggers in an NF, an improved method for assisting in configuring charging triggers in the NF performed in a CHF, corresponding NF and CHF entities, as well as computer programs and computer program products for performing such improved methods in such NF and CHF entities, as defined in and by the accompanying independentclaims. Various embodiments of the improved methods, entities, computer programs and computer program products are defined in and by the accompanying dependent claims.

[0009] According to a first aspect, there is provided a method for configuring and handling charging triggers in a Network Function (NF), where the method is performed by the NF. The method includes obtaining data indicative of a charging trigger, wherein the charging trigger defines a trigger condition for issuing a charging event to a Charging Function (CHF). The method includes obtaining data indicative of one or more additional conditions associated with the charging trigger, and issuing the charging event towards the CHF in response to confirming a fulfillment of both the trigger condition and at least one of the one or more additional conditions.

[0010] As used herein, the “one or more additional conditions” are thus not the conditions provided by e.g. the attribute “triggerType”, such as e.g.“USER_LOCATION_CHANGE”, “RAT_ CHANGE”, “VOLUME_LIMIT”, or any other example enumerated in e.g. Table 6.2.5.3.5-1 of 3GPP TS 32.291. The “one or more additional conditions” are neither any of the additional values / limits provided for such contemporary triggers, such as e.g. in any of the value-attributes “timeLimit”, “volumeLimit64”, “eventLimit”, “maxNumberOfccc”, or similar, of the type “Trigger” as defined in e.g. Table 6.2.5.2.1.5-1 of 3GPP TS 32.291. To the contrary, the “one or more additional conditions” are provided in addition to any such contemporary conditions defined by the attribute “triggerType” and / or such value-attributes. As used herein, that something is “obtained” includes all possible ways of either becoming or already being in possession of this something, such as by for example receiving, fetching, measuring, generating, and similar.

[0011] The envisaged method improves upon contemporary technology in that the one or more additional conditions, which are to be validated alongside the conventional charging trigger conditions defined by e.g. triggerType and similar, improves the flexibility of when exactly to issue a charging event towards the CHF, and in particular in that it may reduce the number of charging events that are issued to the CHF and thereby also reduce the amount of network data generated and transferred due to triggering of charging events. The improved method may also reduce the workload of the NF (such as e.g. a Session Management Function, SMF), as spending of system resources on validating conditions that are not really neededmay be reduced or even avoided. Likewise, the workload of the CHF may also be reduced, as the CHF will be less occupied with having to receive, process and potentially also answer such unnecessary charging events received from the NF. As used herein, terms such as “contemporary technology” and “contemporary charging triggers” means technology and charging triggers that do not include the one or more additional conditions such as defined herein.

[0012] In one or more embodiments of the method, the one or more additional conditions may indicate a time period during which the charging event must occur to be issued to the CHF. This may have the advantage that charging events may be defined as relevant only for a particular time period, such as e.g. for / during a particular date, for a particular day of week, and / or for any other particular time / date of the year. As used herein, a “time period” maybe defined only by a starting date / time and have an open / unspecified ending date / time, be defined only by an ending date / time and have an open / unspecified starting date / time, or be defined by both a starting date / time and an ending date / time. By providing such a particular time period as part of the one or more additional conditions, evaluation of triggers outside this particular time period maybe avoided and result in a reduced usage of system resources and a reduced amount of generated / communicated data traffic on the network. Phrased differently, this may eliminate the need to e.g. having to activate / deactivate triggers to achieve a similar functionality, and in particular improve a contemporary situation in which such activation / deactivation of a particular trigger may only be performed by the CHF in response to an incoming charging data request, which may cause substantial delay between wanting to e.g. deactivate a trigger and being actually capable of doing so.

[0013] In one or more embodiments of the method, the one or more additional conditions maybe for at least one network parameter. The network parameters may e.g. be dependent on the particular type of NF where the trigger is armed. For network exposure, this may e.g. correspond to NF providing the information to the Network Exposure Function (NEF), such as e.g. Unified Data Management (UDM) and / or Policy Control Function (PCF).

[0014] In one or more embodiments of the method, the one or more additional conditions may indicate at least one regional area which a device (such as a user / subscriber device) must be in, enter or leave, for the charging event to be issuedto the CHF. In such an example, the relevant network parameter may be a subscriber (device) location or similar. In one or more embodiments, the one or more additional conditions may e.g. be related to network slicing and slice identification, e.g. based on (single) network slice selection assistance information, i.e. (S-)NSSAI or similar. For example, the one or more additional conditions may require a specific network slice in order to allow issuing of the charging event towards the CHF.

[0015] In one or more embodiments of the method, the one or more additional conditions may indicate at least one Radio Access Technology (RAT) type that a device (such as a user / subscriber) device must utilize for the charging event to be issued to the CHF.

[0016] In one or more embodiments of the method, the method may further include obtaining at least one of the data indicative of the charging trigger and at least part of the data indicative of the one or more additional conditions as part of a charging data response from the CHF. Phrased differently, the one or more additional conditions maybe configured by the CHF, as part of a charging data response received by the NF from the CHF in response to sending a charging data request, or similar.

[0017] In one or more embodiments of the method, the method may further include obtaining at least part of the data indicative of the one or more additional conditions as part of an attribute of the charging trigger. As will be described later herein in more detail, this may e.g. include defining a new attribute (e.g. “triggerRule”) in the type “Trigger”, including the one or more additional conditions.

[0018] In one or more embodiments of the method, the method may further include obtaining the data indicative of the charging trigger as part of data indicative of a charging trigger profile, and the at least one of the one or more additional conditions may be associated with the charging trigger profile. As used herein, a “charging trigger profile” maybe defined as in 3GPP TR 28.826, “Study on Nchf charging services phase 2 improvements and optimizations” or any developments thereof. Providing the one or more additional conditions as part of a trigger profile may have the advantage that the one or more additional conditions may be applied on all charging triggers defmed / indicated by such a trigger profile, thus increasing the flexibility of when the issue charging events further.

[0019] In one or more embodiments of the method, the method may further include obtaining at least part of the data indicative of the one or more additional conditions as part of an attribute of the charging trigger profile. As will be described later herein in more detail, this may e.g. include defining a new attribute (e.g. “triggerProfileRule”) in the corresponding type for the charging trigger profile (e.g., type “TriggerProfilelnfo”, or similar), including the one or more additional conditions.

[0020] According to a second aspect, there is provided a method for assisting in configuring charging triggers in a Network Function (NF), where the method is performed by / in a Charging Function (CHF). The method includes sending a charging data response to the NF, wherein the charging data response includes data indicative of a charging trigger defining a trigger condition for a charging event to be issued to the CHF from the NF, wherein the charging data response further includes one or more additional conditions for issuing the charging event.

[0021] In one or more embodiments of the method, the one or more additional conditions may indicate a time period during which the charging event must occur to be issued to the CHF.

[0022] In one or more embodiments of the method, the one or more additional conditions may be for at least one network parameter.

[0023] In one or more embodiments of the method, the one or more additional conditions may indicate at least one regional area which a device must be in, enter, or leave, for the charging event to be issued to the CHF.

[0024] In one or more embodiments of the method, the one or more additional conditions may indicate at least one RAT type that a device must utilize for the charging event to be issued to the CHF.

[0025] In one or more embodiments of the method, the method may further include providing at least part of the data indicative of the one or more additional conditions as part of an attribute of the charging trigger.

[0026] In one or more embodiments of the method, the method may further include providing the data indicative of the charging trigger as part of data indicative of a charging trigger profile, wherein at least one of the one or more additional conditions is associated with the charging trigger profile. Here, “associated with”implies that the at least one of the one or more additional conditions are to be used to evaluate whether any charging trigger of / defined by the charging trigger profile is to be issued to the CHF.

[0027] In one or more embodiments of the method, the method may further include providing at least part of the data indicative of the at least one of the one or more additional conditions as part of an attribute of the charging trigger profile.

[0028] According to a third aspect, there is provided a Network Function (NF) entity for configuring and handling charging triggers. The NF entity includes processing circuitry, and the processing circuitry is configured to cause the NF entity to obtain data indicative of a charging trigger, wherein the charging trigger defines a trigger condition for issuing a charging event to a Charging Function (CHF) entity. The processing circuitry is further configured to cause the NF entity to obtain data indicative of one or more additional conditions associated with the charging trigger, and issue the charging event towards the CHF entity in response to confirming a fulfillment of both the trigger condition and at least one of the one or more additional conditions. Phrased differently, the processing circuitry is configured to cause the NF entity to perform e.g. the method of the first aspect.

[0029] In one or more embodiments of the NF entity, the processing circuitry may be further configured to cause the NF entity to perform any embodiment of the method of the first aspect as discussed and disclosed herein.

[0030] According to a fourth aspect, there is provided a Charging Function (CHF) entity for assisting in configuring charging triggers in a Network Function (NF) entity. The CHF entity includes processing circuitry configured to cause the CHF entity to send a charging data response to the NF entity, wherein the charging data response includes data indicative of a charging trigger defining a trigger condition for a charging event to be issued to the CHF entity from the NF entity. The charging data response further includes one or more additional conditions for issuing the charging event. Phrased differently, the processing circuitry is configured to cause the CHF entity to perform e.g. the method of the second aspect.

[0031] In one or more embodiments of the CHF entity, the processing circuitry may be further configured to cause the CHF entity to perform any embodiment of the method of the second aspect as discussed and disclosed herein.

[0032] According to a fifth aspect, there is provided a computer program for configuring and handling charging triggers in a Network Function (NF) entity. The computer program includes computer code which, when run on processing circuitry of the NF entity, causes the NF entity to: obtain data indicative of a charging trigger, wherein the charging trigger defines a trigger condition for issuing a charging event to a Charging Function (CHF) entity; obtain data indicative of one or more additional conditions associated with the charging trigger, and issue the charging event towards the CHF entity in response to confirming a fulfillment of both the trigger condition and at least one of the one or more additional conditions. Phrased differently, the computer program may cause the NF entity to perform the method of e.g. the first aspect, or any embodiment thereof discussed and disclosed herein.

[0033] According to a sixth aspect, there is provided a computer program product that includes the computer program of the fifth aspect, and a computer-readable storage medium on which the computer program is stored.

[0034] According to a seventh aspect, there is provided a computer program for assisting in configuring charging triggers in a Network Function (NF) entity. The computer program includes computer code which, when run on processing circuitry of a Charging Function (CHF) entity, causes the CHF entity to send a charging data response to the NF entity, wherein the charging data response includes data indicative of a charging trigger defining a trigger condition for a charging event to be issued to the CHF entity from the NF entity, wherein the charging data response further includes one or more additional conditions for issuing the charging event. Phrased differently, the computer program may cause the CHF entity to perform the method of e.g. the second aspect, or any embodiment thereof discussed and disclosed herein.

[0035] According to an eight aspect, there is provided a computer program product that includes the computer program of the seventh aspect, and a computer- readable storage medium on which the computer program is stored.

[0036] As used herein, a computer-readable storage medium (such as that of e.g. the sixth or eight aspect) may e.g. be non-transitory, and be provided as e.g. a hard disk drive (HDD), solid state drive (SDD), USB flash drive, SD card, CD / DVD, and / or as any other storage medium capable of non-transitory storage of data. In other embodiments, the computer-readable storage medium may be transitory and e.g.correspond to a signal (electrical, optical, mechanical, or similar) present on e.g. a communication link, wire, or similar means of signal transferring.

[0037] Other objects and advantages of the present disclosure will be apparent from the following detailed description, the drawings and the claims. Within the scope of the present disclosure, it is envisaged that all features and advantages described with reference to e.g. the method of the first aspect are relevant for, apply to, and may be used in combination with also the method of the second aspect, the entities of the third and fourth aspects, the computer programs of the fifth and seventh aspects, and the computer program products of the sixth and eight aspects, and vice versa.Brief description of the drawings

[0038] Exemplifying embodiments will be described below with reference to the accompanying drawings, in which:Figure 1 schematically illustrates parts of a communications network for which the present disclosure may be relevant;Figure 2 schematically illustrates a timeline of an exemplary scenario for which the present disclosure may be relevant;Figure 3 schematically illustrates a timeline of another exemplary scenario for which the present disclosure maybe relevant;Figure 4 schematically illustrates a flowchart of one or more embodiments of a method according to the present disclosure;Figure 5 schematically illustrates a flowchart of one or more embodiments of another method according to the present disclosure;Figures 6A and 6B schematically illustrate one or more embodiments of Network Function (NF) entities according to the present disclosure;Figures 7A and 7B schematically illustrate one or more embodiments of (Converged) Charging Function (CHF) entities according to the present disclosure, andFigure 8 schematically illustrates one or more embodiments of a computer program product according to the present disclosure.

[0039] In the drawings, like reference numerals will be used for like elements unless stated otherwise. Unless explicitly stated to the contrary, the drawings show only such elements that are necessary to illustrate the example embodiments, while other elements, in the interest of clarity, may be omitted or merely suggested.Detailed description

[0040] The embodiments of the present disclosure that will be presented later herein may be applied in a communication network such as e.g. a public land mobile network (PLMN), or similar. More in particular, it is envisaged that the embodiments presented herein apply at least to a reference architecture of a fifth-generation telecommunication system (5GS) or later, and parts of such a network especially relevant for the present disclosure will now be described in more detail with reference to Figure 1.

[0041] Figure 1 schematically illustrates part of a (tele) communications network 100, including several examples of Network Functions (NFs) 120, 122, 124, 126 connected together via a Service-Based Interface (SBI) topology built around a common communication bus no. The NFs are respectively a (Converged) Charging Function (CHF) 120, a Session Management Function (SMF) 122, an Access and Mobility Management Function (AMF) 124, a Network Exposure Function (NEF) 126, and a Short Message Service Function (SMSF) 128. Although not shown in Figure 1, the network 100 may of course also include one or more other / additional NFs, or even fewer than the NFs shown in Figure 1. Each one of the NFs 120, 122, 124, 126 and 128 has its own SBI 121, 123, 125, 127, 129 respectively, indicated in text on the format “N{x}”, where “{x}” is the abbreviation for the corresponding NF (such as Nchf for the CHF 120, Nsmf for the SMF 122, and so on). There may of course be other interfaces available, such as e.g. one or more point-to-point interfaces, but these have on purpose been omitted from Figure 1. One or more of the NFs 120, 122, 124, 126, 128 may also have further connections also not shown in Figure 1. For example, the illustrated NFs all form part of a Control Plane, and e.g. the SMF 122 and the AMF 124 may each have connections (via e.g. one or more point-to-pointinterfaces, not shown) to one or more functions of a User Plane. For more details, see e.g. 3GPP TS 23.501.

[0042] It is envisaged that the CHF 120 forms part of a so-called Converged Charging System (CCS) which may in turn interact with a billing system of e.g. a network operator running the network 100. The CHF 120 is responsible for both online and offline charging in a convergent manner, and operates to collect data on e.g. network resource usage from various NFs such as e.g. the SMF 122. To do so, the CHF 120 may provide a service Nchf_ConvergedCharging, including operations such as Create, Update and Release (as specified in 3GPP TS 32.291). The CHF 120 may also provide other services, such as e.g. Nchf SpendingLimitControl (as specified in 3GPP TS 23.502). Using a resource and data model, all operations of e.g. the Nchf_ConvergedCharging maybe based on a HTTP method such as e.g. POST and DELETE. More details on how the CHF 120, according to already proposed architectures, interacts with e.g. the SMF 122 is found in 3GPP TS 32.290.

[0043] An NF such as the SMF 122 may indicate to the CHF 120 that it wants to initiate a charging session, e.g. by sending a charging data request [initial] to the CHF 120. The CHF 120 may, in turn, respond back with a charging data response [initial]. To know which events that are to be monitored, the SMF 122 uses one or more charging triggers. As soon as such a charging trigger is activated, the SMF 122 sends another charging data request [update] to the CHF 120, informing the CHF of which charging trigger that was triggered, and e.g. together with a current data usage count or similar, such that the CHF 120 may properly handle the bookkeeping needed to keep track of e.g. network data usage, service usage, and similar, for which the user is to be billed. The sending of the charging data request [update] maybe referred to as the NF (e.g. SMF 122) issuing a charging event towards the CHF 120. Exactly which charging triggers that are to be used may e.g. be configured directly in the SMF 122 (or any other NF, using e.g. an operating support system), or the CHF 120 may assist in the configuring of charging triggers by providing a list of one or more charging triggers to the SMF 122 as part of e.g. a response to the charging data request [initial] or to the later charging data request [update].

[0044] In contemporary telecommunication systems, a particular charging trigger is considered as being activated as soon as the details pertinent thereto are received from the CHF 120 as part of a charging data response. Phrased differently, the time(or date / time) from which a charging trigger is to be enabled is decided by (i.e., aligned with) the time at which the response from the CHF 120 is received. In addition, for default charging triggers configured directly in an NF (which charging triggers may not be overridden by the CHF 120), the charging trigger may instead be enabled from the time it was configured to be enabled.

[0045] As mentioned earlier herein, contemporary charging triggers include only basic conditions for when the charging trigger is to be triggered and the corresponding charging event issued towards the CHF 120. Examples of such conditions may include that the associated user equipment (UE) changes location, changes RAT type, exceeds a volume and / or time limit, or similar. There is, however, no possibility to e.g. allow for charging events to be issued only in more specific scenarios.

[0046] As an example of the shortcomings of contemporary charging triggers, it may in some scenarios be desirable to provide a special charging rate when a subscriber is entering into a specific location and / or when the subscriber starts using a specific RAT type. Using contemporary charging triggers, this may be achieved by enabling a charging trigger for when the subscriber changes location (e.g., “USER_LOCATION_CHANGE”) and / or for when the subscriber changes RAT type (e.g., “RAT_CHANGE”). Enabling these charging triggers in the NF may e.g. be performed by providing the details as part of a charging data response sent from the CHF 120 to the NF (e.g. SMF 122). As soon as the SMF 122 receives such a response, these charging triggers become active, and the SMF 122 will start to issue charging events to the CHF 120 everytime the subscriber changes location and / or RAT type. The CHF 120 would have to receive and analyze each such charging event, in order to detect whether the current location and / or RAT type of the subscriber matches the specific location and / or specific RAT type. In summary, there maybe unnecessary load on the system as charging events are likely issued even when the subscriber is not at the specific location and / or uses the specific RAT type.

[0047] As a further example of the above-mentioned shortcomings, reference is made also to Figure 2 which schematically illustrates a timeline 200 of another scenario wherein it is desirable to e.g. charge a fixed monetary sum each time a subscriber device enters location “A”. At a first time instance 210, the charging triggers in the NF are configured e.g. by receiving the specific details thereof as partof a charging data response 212 from the CHF 120. The charging triggers become active as soon as the charging data response 212 is received, i.e. at the first time instance 210. The charging data response 212 indicates that the charging trigger condition is “USER_LOCATION_CHANGE”. The NF may e.g. be a Charging Trigger Function (CTF) forming part of the SMF 122. At a second time instance 220, the subscriber changes location to location “B”, and the SMF 122 responds by issuing a first charging event 222 towards the CHF 120 including data indicating that the subscriber is now at location “B”. After a while, at a third time instance 230, the subscriber changes location to location “C”, and the SMF 122 responds by issuing a second charging event 232 towards the CHF 120 including data indicating that the subscriber is now at location “C”. At a fourth time instance 240, the subscriber arrives at location “A”, and the SMF 122 responds by issuing a third charging event 242 towards the CHF 120 including data indicating that the subscriber is now at the specific location “A”, such that the CHF 120 may now detect this and charge the fixed monetary sum associated therewith. After yet a while, at a fifth time instance 250, the subscriber moves on to location “D”, and the SMF 122 responds by issuing a fourth charging event 252 towards the CHF 120, etc.

[0048] In the scenario shown in Figure 2, only the third charging event 242 was relevant to the desire to charge a fixed monetary sum when the subscriber enters the location “A”. However, due to limitations of contemporary charging triggers, a charging event was issued towards the CHF 120 for every time the subscriber changed location, independent of whether the change was to the location “A” or not, thus resulting in an unnecessary load of the network as multiple charging events (including e.g. the charging events 222, 232 and 252) had to be sent by the SMF 122 and received and processed by the CHF 120.

[0049] As yet another example of the above-mentioned shortcomings, reference is made also to Figure 3 which schematically illustrates a timeline 300 of yet another scenario, wherein it instead desirable that certain charging triggers are only active during a limited time period. For example, this maybe relevant if a service provider wants to e.g. offer a particular service during only this limited time period, or similar. For example, it maybe assumed that there is a desire for the limited time period to extend between a starting time instance Ti and an ending time instance T2.

[0050] If using the CHF 120 to configure the charging triggers in the SMF 122, the CHF 120 may only update charging triggers in the SMF 122 as part of a charging data response, i.e. the CHF 120 must first receive a charging data request from the SMF 122 to which it may respond with the charging data response. As a consequence, there will likely be a first period 310 during which charging triggers will be activated (for some sessions) before the starting time instance Ti, and also likely a second period 320 during which charging triggers will be activated (for some sessions) after the starting time instance Ti. Consequently, during the first period 310, charging events will be issued towards the CHF 120 even though the starting time instance Ti still lies ahead. During the second period 320, there will be missed charging events (for some sessions), as the charging triggers for these sessions are not activated in time / before the starting time instance Ti.

[0051] Following the same principle, the only way (using contemporary charging triggers) for the CHF 120 to disable one or more charging triggers in e.g. the SMF 122 is as part of a charging data response to an incoming charging data request. As the CHF 120 has no control over when such charging data requests will arrive, the best the CHF 120 can do is to start responding to all charging data requests incoming after the ending time instance T2 with instructions to disable the relevant charging triggers (e.g., by not including the relevant charging triggers in a list of charging triggers provided as part of the charging data response). This will, however, likely result in a third period 330 during which (for some sessions) charging triggers will still be issued towards the CHF 120 even though the ending time instance T2 has already passed.

[0052] In summary of Figure 3, it is thus noted that when using contemporary charging triggers to enable the desired wish of only issuing charging triggers during the time interval extending between Ti and T2, there is a risk of unnecessary charging events being issued during the first and third periods 310 and 330, as well as a risk of charging events being missed during the second period 320.

[0053] In summary of both Figures 2 and 3, it is further noted that when using contemporary charging triggers, there is a possibility for the SMF / NF 122 having to evaluate charging trigger conditions which are not needed and hence reducing the capacity of the SMF 122. Further, there is a possibility for unnecessary consumption of network bandwidth, by issuing unnecessary charging events towards the CHF 120.Further, the CHF 120 will likely spend its system resources on receiving, processing and perhaps also answering incoming charging data requests which are unnecessarily sent from the SMF 122 due to the above. As a result, in at least the above-described situations illustrated in Figures 2 and 3, there is a risk of unnecessary spending of both computing and network resources due to the less flexible contemporary charging triggers, and e.g. an increased Total Cost of Ownership (TCO) following therefrom.

[0054] Various examples of how various methods of the present disclosure resolve the above-described issues with contemporary charging triggers will now be described in more detail with reference also to Figures 4 and 5.

[0055] Figure 4 schematically illustrates a flowchart of an exemplary method 400 for configuring and handling charging triggers in an NF as envisaged herein. The method 400 includes (e.g. as part of an operation S410) to obtain data indicative of a charging trigger, wherein the charging trigger defines a trigger condition for issuing a charging event to a CHF. The trigger condition may e.g. be “USER_LOCATION_CHANGE”, “RAT_ CHANGE”, “VOLUME_LIMIT”, or any other example enumerated in e.g. Table 6.2.5.3.5-1 of 3GPP TS 32.291 or any similar current or later standard. The trigger condition may also be envisaged to include e.g. one or more additional values / limits such as e.g. “timeLimit”, “volumeLimit64”, “eventLimit”, “maxNumberOfccc” or similar, wherein the labels used herein are of course only used as examples. The method 400 further includes (e.g. as part of an operation S412) to obtain data indicative of one or more additional conditions associated with the charging trigger, i.e. one or more conditions in addition to the trigger condition. The method 400 further includes (e.g. as part of an operation S414) issuing the charging event towards the CHF in response to confirming a fulfillment of both the trigger condition and at least one of the one or more additional conditions. Phrased differently, in a method as envisaged herein, it is not sufficient to only evaluate whether the trigger condition (as found in contemporary charging triggers) is fulfilled. Instead, it must also be verified that also at least one of the additional conditions is fulfilled.

[0056] As envisaged herein, the one or more additional conditions (which may also be referred to as one or more (additional) “rules” or similar) provide an improved flexibility of deciding when to issue a particular charging event, and inparticular provide a possibility to reduce the number of charging events issued towards a CHF in order to enable the use of more specific charging scenarios as described earlier herein (e.g. as described with reference to one or both of Figures 2 and 3).

[0057] For example, in some embodiments, such an additional condition may indicate a time period during which the charging event must occur to be issued towards the CHF. The time period may e.g. be set in the CTF / SMF for default triggers, maybe overridden by the CHF via a charging data response to a charging data response received from the SMF / CTF (or any other NF). It is also envisaged that by providing a zero value, or by not defining any such time period as an additional condition, any previously defined such time period may be reset and the NF may continue with a default behavior instead. The time period may e.g. be defined by a starting date / time, such as a particular year; year and month; year, month and day; year, month, day and hour; year, month, day, hour and minute; year, month, day, hour, minute and second, or similar. Such a starting date / time may also e.g. be defined to be recurring, e.g. for a particular month of any year, a particular month and day of any year, and so on. The time period may e.g. be defined also by a corresponding ending date / time in addition to the starting date / time, or e.g. by only an ending date / time in which it maybe assumed that the starting date / time corresponds to the time at which the data indicative of the additional condition is obtained by the NF. Phrased differently, the time period may be open (i.e. have only a starting date / time) or closed (i.e. have both a starting date / time and an ending date / time). The use of the envisaged time period may for example help to resolve the issues described with reference to Figure 3, as the CHF 120 may provide the additional condition and time period well ahead of the desired starting time instance Ti, such that the NF / SMF 122 is ready (for all sessions) to start issuing charging events towards the CHF 120 only after the starting time instance Ti, and to e.g. stop issuing charging events towards the CHF 120 after the ending time instance T2, without the risk of unnecessary or missed charging events during the first, second and third time periods 310, 320 and 330. As will be described in more detail later herein, the time period may e.g. be defined as one or more new attributes (dedicated only to the time period) to an existing charging trigger type, or e.g. as part of a new attribute to the charging trigger type dedicated to more than one such additional condition (for e.g. a rule set or similar).

[0058] In some embodiments, the one or more additional conditions may instead (or in addition) be for at least one network parameter. Examples of network parameters may e.g. include a location of a subscriber (device), a RAT type, or e.g. one or more other parameters which may or may not be dependent on the NF where the triggers are armed. For network slices, network parameters may e.g. include the S-NSSAI, the originating NF in the case of NEF, and / or Quality of Service (QoS) information. For example, the one or more additional conditions may indicate at least one regional area in which a (subscriber) device must be in, enter, or leave, for the charging event to be issued to the CHF, and / or e.g. a requirement to (start / end to) use a particular network slice. For example, an additional condition may stipulate that the device must be in location “A” for the charging trigger to be triggered and the charging event to be issued towards the CHF, in addition to e.g. one or more charging trigger conditions as defined in contemporary charging triggers. The charging trigger condition may e.g. be “USER_LOCATION_CHANGE”, and the additional condition may stipulate that a charging event is only to be issued if the user / subscriber changes location to location “A”, or e.g. that the user / subscriber changes location from location “A”. For example, an additional condition stipulating that the (new) user location must be “A” would help to resolve the issue described with reference to Figure 2, as none of the unnecessary charging events 222, 232 and 252 would then be issued towards the CHF 120, as both the charging trigger condition (“USER_LOCATION_CHANGE”) and the additional condition (new location is “A”) would both be fulfilled at the second, third and fifth time instances 220, 230 and 250. As another example, the one or more additional conditions may stipulate that the device must use a certain RAT type, or similar, and charging events will thus be prevented from being issued towards the CHF 120 in situations wherein a charging trigger condition “RAT_CHANGE” is fulfilled but not the additional condition of changing to / from a particular RAT type.

[0059] As envisaged herein, the provisioning of the one or more additional conditions may be implemented by introducing one or more changes to 3GPP TS 32.291. In particular, this maybe accomplished by for example introducing a new attribute (e.g., “triggerRule”) in the definition of the type Trigger, as shown in Table 1.Table 1. Envisaged addition to type Trigger

[0060] The type “rule” may be defined using any suitable format, e.g. as Javascript Object Notation (JSON) or any other suitable text format which the NF may process and extract the one or more additional conditions from. As an example, using JSON, a structure of “rule” maybe defined as follows:“rule” : { compositeConditionType : “All / anyOf ’,[ simpleConditionType : “All / anyOf”,[{ paramet erName: String, parameterType: String, parameterValue: String, comparator: String (regExp / EQ / GT / GTE / LT / LTE)},{ triggerActiveStartDateTime : DateTime, triggerActiveEndDateTime: DateTime}]]} wherein “(composite / simple)conditionType: All” indicates all conditions specified in an array need to be fulfilled, and wherein “(composite / simple)conditionType: anyOf’ indicates that at least one condition specified in an array needs to be fulfilled. Likewise, “regExp” indicates that string value parameters maybe compared with regular expressions / pattern matching; “EQ” indicates a condition that a configured parameter value is equal to a network parameter; “GT” / ”LT” indicates a condition that a configured parameter value is greater / less than a network parameter; and “GTE” / ”LTE” indicates a condition that a configured parameter value is greater / less than or equal to a network parameter. Leaving triggerActiveStartD at eTime empty or not included may correspond to a desire to start issuing charging events as soon as the charging data response is received from the CHF. Leaving triggerActiveEndDateTime empty or not included may correspond to a desire to keep issuing charging events for an unspecified time after the triggerActiveStartDateTime, and leaving both triggerActiveStartDateTime and triggerActiveEndDateTime empty or not included may indicate that any previously configured time period for when the charging events should be issued towards the CHF should be removed and a default behavior assumed instead, or similar.

[0061] As an example, if it is desirable to issue charging events towards the CHF only when a location of the user / subscriber is “0123X”, a corresponding charging trigger maybe defined as follows: triggerType : USER_LOCATION_CHANGE trigger Rule:{ compositeConditionType: “anyOf”, [ simpleConditionType: “anyOf”,[{ parameterName:“PDUSessionCharginglnformation / userLocationlnfo / eutraLocation / ecgi / eutra Cellld”, parameterType: “HexaDecimal”, parameterValue: “0123X”, comparator: “EQ”}]]}

[0062] As another example, if it is desirable to issue charging events only between 1stto 2ndJanuary 2023, a corresponding charging trigger maybe defined as: triggerType : USER_LOCATION_CHANGE trigger Rule:{ compositeConditionType: “anyOf”,[ simpleConditionType: “All”,[{ triggerActiveStartDateTime : “01-01-2023 00:00:00”, triggerActiveEndDateTime : “02-01-2023 00:00:00” }]]}

[0063] As yet another example, if it is desirable to issue charging events towards the CHF only when the RAT type is “EUTRA” and the time period is between 1stto 2ndJanuary 2023, or when the RAT type is “GERAN”, a corresponding charging trigger maybe defined as follows: triggerType : RAT_CHANGE trigger Rule:{ compositeConditionType: “anyOf”,[{ simpleConditionType: “All”,[{ parameterName:“PDUSessionCharginglnformation / pduSessionlnformation / ratType”, parameterType: “String”, parameterValue: “EUTRA”},{ triggerActiveStartD at eTime : “01-01-2023 00:00:00”, triggerActiveEndDateTime : “02-01-2023 00:00:00”,}]},{simpleConditionType: “All”, [{ paramet erName: “PDUSessionCharginglnformation / pduSessionlnformation / ratType”, parameterType: “String”, parameterValue: “EUTRA”}]}]}

[0064] In other example embodiments, it is envisaged that e.g. the parameters triggerActiveStartD at eTime and / or triggerActiveEndDateTime may instead be provided as their own attributes in the type Trigger, or similar.

[0065] As also envisaged herein, the data indicative of the charging trigger may also be obtained as part of data indicative of a so-called charging trigger profile (as introduced in e.g. 3GPP TR 28.826, “Study on Nchf charging services phase 2 improvements and optimizations”). In such a case, at least one of the one or more additional conditions may instead (or in addition) be associated with the charging trigger profile, and thus apply to all charging triggers defined by the charging trigger profile. Phrased differently, if an additional condition as envisaged herein is associated with a charging trigger profile, a charging event caused by any charging trigger included in such a charging trigger profile may only be issued if both the charging triggers own charging trigger condition and the one or more additional conditions associated with the charging trigger profile are simultaneously fulfilled. This may allow e.g. further flexibility for the CHF 120 to control when charging events are to be issued or not. As envisaged herein, the provisioning of the one or more additional conditions in association with a charging trigger profile may be implemented by introducing one or more changes to 3GPP TR 28.826 (or anysubsequent such document). In particular, this maybe accomplished by for example introducing a new attribute (e.g., “triggerProfileRule”) in the definition of the data type TriggerProfilelnfo, as shown in Table 2.Table 2. Envisaged addition to type TriggerProfilelnfo

[0066] The type “rule” for the charging trigger profile may be defined using any suitable form, e.g. similarly to the “rule” for the charging trigger discussed with reference to Table 1 (with e.g. names “triggerXXX” modified to “triggerProfileXXX” or similar). Generally herein, the attribute names used to defme / provide the envisaged one or more additional conditions are made to align with those of contemporary 3GPP standards, but may of course also be changed as desired.

[0067] As envisaged herein, an NF (such as an SMF) may e.g. also send its currently implemented one or more additional conditions (defined e.g. using the “rule”(s) defined above) to the CHF as part of a charging data request. The CHF may receive this information, and use it to decide how to e.g. update such one or more additional conditions in a later charging data response sent to e.g. the same NF or some other NF, and / or for a same session or one or more different sessions.

[0068] The various tables provided herein are only examples of one or more possible ways in which to embody the envisaged method. There may of course also be other alternatives for how to define and use the envisaged concept of providing one or more additional conditions for issuing charging events in addition to the charging trigger conditions already present in contemporary charging triggers. It may for example be envisaged to not include multiple additional conditions as part of a same “rule” attribute, but to instead include each additional condition as its own attribute, or similar.

[0069] As a minimal envisaged requirement, the NF should, in addition to a charging trigger condition as already defined in contemporary charging triggers, also obtain one or more additional conditions for when to issue a charging event based on the charging trigger, and validate that both the charging trigger condition as well as at least one of the one or more additional conditions are fulfilled before issuing the charging event towards the CHF.

[0070] Figure 5 schematically illustrates a flowchart of an exemplary method 500 for assisting in configuring charging triggers in an NF as envisaged herein. The method 500 is performed in / by a CHF and includes (e.g. as an operation S512) to send a charging data response to the NF, wherein the charging data response includes data indicative of a charging trigger defining a trigger condition for a charging event to be issued to the CHF. The charging data response further includes one or more additional conditions for issuing the charging event, such as already described in more detail earlier herein. Phrased differently, the method 500 illustrates how it is envisaged that in some embodiments, the CHF is responsible for providing the one or more additional conditions to the NF as part of a charging data response. As described earlier herein, the one or more additional conditions may define a time period during which the charging event must occur to be issued towards the CHF, and the one or more additional conditions may also be for at least one network parameter (such as subscriber location, RAT type, or similar). The one or more additional conditions may be provided as part of an attribute of a charging trigger data type (such as illustrated in Table 1), and / or e.g. as part of an attribute of a charging trigger profile data type (such as illustrated in Table 2), or similar. Sending of the charging data response may e.g. be performed in response to first receiving(e.g. as an operation S510) a charging data request from an NF, e.g. from the NF to which the charging data response is sent.

[0071] The present disclosure also envisages to provide NF and CHF entities configured to perform the respective methods 400 and 500 described earlier herein, which will now be described in more detail with reference also to Figures 6A and 6B, and 7A and 7B, respectively, as well as with reference also to Figure 8.

[0072] Figure 6A schematically illustrates, in terms of a number of functional units, the components of an embodiment of a Network Function (NF) entity 600 according to the present disclosure. The NF entity 600 is configured for configuring and handling charging triggers in accordance with e.g. the method 400 described herein with reference to Figure 4, and includes processing circuitry 610. The processing circuitry 610 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 810a (see Figure 8 and the description thereof), e.g. in form of a storage medium 630 that may also form part of the NF entity 600. The processing circuit 610 may further be provided as at least one application specific integrated circuit (ASIC), or field-programmable gate array (FPGA).

[0073] Particularly, the processing circuitry 610 is configured to cause the NF entity 600 to perform a set of operations, or steps, as disclosed above e.g. when describing the method 400 illustrated in Figure 4. For example, the storage medium 630 may store a set of operations, and the processing circuitry 610 may be configured to retrieve the set of operations from the storage medium 630 to cause the NF entity 600 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus, the processing circuitry 610 is thereby arranged to execute methods associated with a NF as disclosed herein e.g. with reference to Figure 4.

[0074] The storage medium 630 may also include persistent storage, which, for example, can be any single or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0075] The NF entity 600 may further include a communications interface 620 for communications with other entities, functions, nodes, and devices of thecommunication network. For example, the communications interface 620 may allow the NF entity 600 to communicate with e.g. a CHF entity, and / or with other NFs. As such, the communication interface 620 may include one or more transmitters and receivers, including analogue and / or digital components.

[0076] The processing circuitry 610 controls the general operation of the NF entity 600 e.g. by sending data and control signals to the communications interface 620 and the storage medium 630, by receiving data and reports from the communications interface 620, and by retrieving data and instructions from the storage medium 630. Other components, as well as their related functionality, of the NF entity 600 are omitted in order not to obscure the concepts presented herein.

[0077] Figure 6B schematically illustrates, in terms of a number of functional modules 610a, 610b and 610c, the components of a NF entity 600 according to one embodiment of the present disclosure. The NF entity 600 includes at least a first obtain module 610a configured to perform operation S410 of the method 400 described with reference to Figure 4. The NF entity 600 also includes a second obtain module 610b configured to perform operation S412, and an issue module 610c configured to perform operation S414. The NF entity 600 may also include one or more optional functional modules (illustrated by the dashed box 6iod), such as for example a network parameter module configured to obtain various network parameters, and / or a date / time module configured to obtain a current date / time, as required to evaluate the one or more additional conditions.

[0078] In general terms, each functional module 6ioa-d may be implemented in hardware or in software. Preferably, one or more or all functional modules 6ioa-d maybe implemented by the processing circuitry 610, possibly in cooperation with the communications interface 620 and / or the storage medium 630. The processing circuitry 610 may thus be arranged to from the storage medium 630 fetch instructions as provided by a functional module 6ioa-d, and to execute these instructions and thereby perform any operations of the method 400 performed by / in the NF entity 600 as disclosed herein. The processing circuitry 610, storage medium 630 and communications interface 620 may e.g. also be configured to implement a Charging Trigger Function (CTF) as described herein.

[0079] Figure 7A schematically illustrates, in terms of a number of functional units, the components of an embodiment of a (Converged) Charging Function (CHF)entity 700 according to the present disclosure. The CHF entity 700 is configured for assisting in configuring charging triggers of an NF entity (such as the NF entity 600), and includes processing circuitry 710. The processing circuitry 710 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 810b (see Figure 8 and the description thereof), e.g. in form of a storage medium 730. The processing circuit 710 may further be provided as at least one application specific integrated circuit (ASIC), or field-programmable gate array (FPGA).

[0080] Particularly, the processing circuitry 710 is configured to cause the CHF entity 700 to perform a set of operations, or steps, as disclosed above e.g. when describing the method 500 illustrated in Figure 5. For example, the storage medium 730 may store a set of operations, and the processing circuitry 710 maybe configured to retrieve the set of operations from the storage medium 730 to cause the CHF entity 700 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus, the processing circuitry 710 is thereby arranged to (at least cause the CHF entity 700 to) execute methods as disclosed herein e.g. with reference to Figure 5.

[0081] The storage medium 730 may also include persistent storage, which, for example, can be any single or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0082] The CHF entity 700 may further include a communications interface 20 for communications with other entities, functions, nodes, and devices of the communication network. For example, the communications interface 720 may allow the CHF entity 700 to communicate with (another) NF entity, such as the NF entity 600. As such, the communication interface 720 may include one or more transmitters and receivers, including analogue and / or digital components.

[0083] The processing circuitry 710 controls the general operation of the CHF entity 700 e.g. by sending data and control signals to the communications interface 720 and the storage medium 730, by receiving data and reports from the communications interface 720, and by retrieving data and instructions from the storage medium 730. Other components, as well as their related functionality, of the CHF entity 700 are omitted in order not to obscure the concepts presented herein.

[0084] Figure 7B schematically illustrates, in terms of at least one functional modules 710a, the components of a CHF entity 700 according to one embodiment of the present disclosure. The CHF entity 700 includes at least a send module 710a configured to perform operation S512 of the method 500 described with reference to Figure 5. The CHF entity 700 may also include one or more optional functional modules (as illustrated by the dashed box 710b), such as for example a condition generation module configured to generate / decide the one or more additional conditions as discussed earlier herein, and / or a receive module for receiving a charging data request from an NF (and configured to e.g. perform operation S510 that may form part of the method 500).

[0085] In general terms, each functional module 710a and 710b may be implemented in hardware or in software. Preferably, one or all functional modules 710a and 710b may be implemented by the processing circuitry 710, possibly in cooperation with the communications interface 720 and / or the storage medium 730. The processing circuitry 710 may thus be arranged to from the storage medium 730 fetch instructions as provided by a functional module 710a and 710b, and to execute these instructions and thereby perform any operation(s) of the method 500 performed by the CHF entity 700 as disclosed herein.

[0086] The CHF entity 700 and / or NF entity 600 may be provided as a standalone device or as part of at least one further device. For example, the CHF entity 700 and / or NF entity 600 maybe provided in a node of the core network. Alternatively, functionality of the CHF entity 700 and / or NF entity 600 maybe distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part (such as e.g. the core network) or maybe spread between at least two such network parts. For example, instructions that are required to be executed in real time maybe performed in a device, or node, operatively closer to e.g. the cell than instructions that are not required to be performed in real time. In this respect, at least part of the CHF entity 700 and / or NF entity 600 may reside in the radio access network, such as in the radio access network node, for cases when embodiments as disclosed herein are performed in real time.

[0087] Thus, a first portion of the instructions performed by the CHF entity 700 and / or NF entity 600 maybe executed in a first device, and a second portion of the instructions performed by the CHF entity 700 and / or NF entity 600 maybeperformed in a second device. The herein disclosed embodiments are however not limited to any particular number of devices on which the instructions performed by the CHF entity 700 and / or NF entity 600 maybe executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a CHF entity 700 and / or NF entity 600 residing in a cloud computational environment. Therefore, although e.g. a single processing circuitry 610 and 710 is illustrated in each of Figures 6A and 7A, the processing circuitry 610 and 710 maybe distributed among a plurality of devices, or nodes. The same applies also to the various functional modules 6ioa-d and 7ioa-b of Figures 6B and 7B and the computer programs 820a and 820b of Figure 8.

[0088] Various computer program products according to the present disclosure will now be described in more detail with reference to Figure 8.

[0089] Figure 8 schematically illustrates a computer program product 810a, 810b including computer readable means 830. On the computer readable means 830, a computer program 820a can be stored, which computer program 820a can cause the processing circuitry 610 and thereto operatively coupled entities and devices, such as the communication interface 620 and the storage medium 630, to execute method 400 according to embodiments described herein with reference to Figure 4. The computer program 820a and / or computer program product 810a may thus provide means for performing any steps of the method 400 performed by the NF entity 600 as disclosed herein. On the computer readable means 830, a computer program 820b can also be stored, either in addition to or instead of the computer program 820a, which computer program 820b can cause the processing circuitry 710 and thereto operatively coupled entities and devices, such as the communication interface 720 and the storage medium 730, to execute method 500 according to embodiments described herein with reference to Figure 5. The computer program 820b and / or computer program product 810b may thus provide means for performing any steps of the method 500 performed by the CHF entity 700 as disclosed herein.

[0090] In the example of Figure 8, the computer program product 810a, 810b and computer readable means 830 are illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 810a, 810b and computer readable means may also be embodied as a memory, such as a random-access memory (RAM), a read-only memory (ROM), anerasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 820a, 820b is here schematically shown as a track on the depicted optical disk, the computer program 820a, 820b can be stored in any way which is suitable for the computer program product 810a, 810b.

[0091] In summary, the present disclosure presents an improved way of configuring and handling charging triggers in an NF, wherein, in addition to charging trigger conditions of contemporary charging triggers, there is provided one or more additional conditions which must also be fulfilled before any charging event is issued towards a CHF. Such additional conditions provides the means necessary to increase the flexibility of when to issue charging events, e.g. by requiring the events to take place during a specific time, for a specific location and / or RAT type of the subscriber, or similar, which may allow to reduce or even avoid unnecessary load of the network, NF and CHF. This is important, as charging triggers play a critical role in e.g. rating conditions and what events to be applied for session-based charging or event -based charging, and the present disclosure thereby provides an improvement in at least this field.

[0092] Although features and elements may be described above in particular combinations, each feature or element may be used alone without the other features and elements or in various combinations with or without other features and elements. Additionally, variations to the disclosed embodiments may be understood and effected by the skilled person in practicing the claimed invention as defined by the appended patent claims, from a study of the drawings, the disclosure, and the appended claims themselves. In the claims, the words “comprising” and “including” does not exclude other elements, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that certain features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.

Claims

CLAIMS1. A method (400) for configuring and handling charging triggers in a Network Function, NF, the method being performed by the NF, the method comprising:- obtaining (S410) data indicative of a charging trigger, wherein the charging trigger defines a trigger condition for issuing a charging event to a Charging Function, CHF;- obtaining (S412) data indicative of one or more additional conditions associated with the charging trigger, and- issuing (S414) said charging event towards the CHF in response to confirming a fulfillment of both the trigger condition and at least one of the one or more additional conditions.

2. The method according to claim 1, wherein the one or more additional conditions indicate a time period ([T1,T2]) during which the charging event must occur to be issued to the CHF.

3. The method according to claim 1 or 2, wherein the one or more additional conditions is for at least one network parameter.

4. The method according to any one of claims 1 to 3, wherein the one or more additional conditions indicate at least one regional area which a device must be in, enter, or leave, for the charging event to be issued to the CHF.

5. The method according to any one of the preceding claims, wherein the one or more additional conditions indicate at least one Radio Access Technology, RAT, type that a device must utilize for the charging event to be issued to the CHF.

6. The method according to any one of the preceding claims, further comprising obtaining at least one of the data indicative of the charging trigger and at least part of the data indicative of the one or more additional conditions as part of a charging data response from the CHF.

7. The method according to any one of the preceding claims, further comprising obtaining at least part of the data indicative of the one or more additional conditions as part of an attribute of the charging trigger.

8. The method according to any one of the preceding claims, further comprising obtaining the data indicative of the charging trigger as part of data indicative of a charging trigger profile, and wherein the at least one of the one or more additional conditions is associated the charging trigger profile.

9. The method according to claim 7, further comprising obtaining at least part of the data indicative of the one or more additional conditions as part of an attribute of the charging trigger profile.

10. A method (500) for assisting in configuring charging triggers in a Network Function, NF, the method being performed by a Charging Function, CHF, the method comprising:- sending (S512) a charging data response to the NF, wherein the charging data response comprises data indicative of a charging trigger defining a trigger condition for a charging event to be issued to the CHF from the NF, wherein the charging data response further comprises one or more additional conditions for issuing the charging event.

11. The method according to claim 10, wherein the one or more additional conditions indicate a time period ([Ti, T2]) during which the charging event must occur to be issued to the CHF.

12. The method according to claim 10 or 11, wherein the one or more additional conditions is for at least one network parameter.

13. The method according to any one of claims 10 to 12, wherein the one or more additional conditions indicate at least one regional area which an end user device must be in, enter, or leave, for the charging event to be issued to the CHF.14- The method according to any one of claims 10 to 13, wherein the one or more additional conditions indicate at least one Radio Access Technology, RAT, type that a user device must utilize for the charging event to be issued to the CHF.

15. The method according to any one of claims 10 to 14, further comprising providing at least part of the data indicative of the one or more additional conditions as part of an attribute of the charging trigger.

16. The method according to any one of claims 10 to 15, further comprising providing the data indicative of the charging trigger as part of data indicative of a charging trigger profile, wherein at least one of the one or more additional conditions is associated with the charging trigger profile.

17. The method according to claim 16, further comprising providing at least part of the data indicative of the at least one of the one or more additional conditions as part of an attribute of the charging trigger profile.

18. A network function, NF, entity (600) for configuring and handling charging triggers, the NF entity comprising processing circuitry (610), the processing circuitry being configured to cause the NF entity to:- obtain (S410) data indicative of a charging trigger, wherein the charging trigger defines a trigger condition for issuing a charging event to a Charging Function, CHF, entity (700);- obtain (S412) data indicative of one or more additional conditions associated with the charging trigger, and- issue (S414) said charging event towards the CHF entity in response to confirming a fulfillment of both the trigger condition and at least one of the one or more additional conditions.

19. The NF entity of claim 18, wherein the processing circuitry is further configured to perform the method (400) according to any one of claims 2 to 9.

20. A Charging Function, CHF, entity (700) for assisting in configuring charging triggers in a Network Function, NF, entity (600), the CHF entity comprisingprocessing circuitry (710), the processing circuitry being configured to cause the CHF entity to:- send (S512) a charging data response to the NF entity, wherein the charging data response comprises data indicative of a charging trigger defining a trigger condition for a charging event to be issued to the CHF entity from the NF entity, wherein the charging data response further comprises one or more additional conditions for issuing the charging event.

21. The CHF entity according to claim 20, wherein the processing circuitry is further configured to perform the method (500) according to any one of claims 11 to 17.

22. A computer program (820a) for configuring and handling charging triggers in a Network Function, NF, entity (600), the computer program comprising computer code which, when run on processing circuitry (610) of the NF entity, causes the NF entity to:- obtain (S410) data indicative of a charging trigger, wherein the charging trigger defines a trigger condition for issuing a charging event to a Charging Function, CHF, entity (700);- obtain (S412) data indicative of one or more additional conditions associated with the charging trigger, and- issue (S414) said charging event towards the CHF entity in response to confirming a fulfillment of both the trigger condition and at least one of the one or more additional conditions.

23. A computer program product (810a) comprising a computer program (820a) according to claim 22, and a computer-readable storage medium (830) on which the computer program is stored.

24. A computer program (820b) for assisting in configuring charging triggers in a Network Function, NF, entity (600), the computer program comprising computer code which, when run on a processing circuitry (710) of a Charging Function, CHF, entity (700), causes the CHF entity to:- send (S512) a charging data response to the NF entity, wherein the charging data response comprises data indicative of a charging trigger defining a trigger condition for a charging event to be issued to the CHF entity from the NF entity, wherein the charging data response further comprises one or more additional conditions for issuing the charging event.

25. A computer program product (810b) comprising a computer program (820b) according to claim 24, and a computer-readable storage medium (830) on which the computer program is stored.

Images