Patent Application
20240334165
Subject matter disclosed herein relates to charging in a communication network and particularly relates to controlling charging-related signaling.
A network function (NF) in a communication network may request charging from a charging function (CHF), according to the service-based architecture specified in the Technical Specification (TS) 32.290 provided by the Third Generation Partnership Project (3GPP). Decisions by the NF regarding when to request a start of charging depend on internal settings at the NF or depend on polices received from a Policy Control Function (PCF). If the charging is session-based, a need exists for the CHF to set triggers controlling which service events for which the NF shall report usage or request a service quota from the CHF, with such triggers referred to as “mid-session triggers”.
One or more triggers may be enabled by default at the NF associated with the service consumption, although the CHF may override such triggers. “Triggers” in these contexts represent conditions or events that cause the NF to send charging messages towards the CHF.
There are no generic triggers, with all triggers being service dependent.
However, there are certain triggers defined in 3GPP TS 32.255 that are to a large extent applicable for all types of services, at least in session-based charging scenarios. Such triggers include: (1) a start-of-service/session trigger associated with requesting to use a new service or starting a session; (2) a time limit trigger prompting reporting after a specific time has passed since previous report; (3) a volume limit trigger prompting reporting after a specific volume has been used since previous report; (4) an event limit trigger prompting reporting after a specific number of events has been used since previous report; (5) a charging-condition changes trigger prompting reporting after a number of other triggers has been recorded since previous report; and (6) an end-of-service/session associated with ending the service or session.
Triggering on the above bases or conditions provides good flexibility, depending on the needs of the CHF, and limits the loss of data in instances of failure at the consumer NF. However, there are limited mechanisms available at the CHF with respect to controlling the processing and communication burdens imposed on it as a consequence of NFs in the network sending charging messages towards it.
A Charging Function (CHF) of a communication network signals a payload size limit to a Charging Trigger Function (CTF) in the network, and the CTF applies the payload size limit to restrict the maximum payload of one or more charging messages sent by the CTF towards the CHF. Payload limits determined by the CHF depend, for example, on any one or more of the type(s) of communication services involved, the involved subscribers, or load at the CHF. “Load” refers to any one or more of processing load, storage load, or communication load, and the CHF in an example implementation may choose smaller payload limits to reduce its processing or storage loads, or choose larger payload limits, e.g., up to some maximum size, to reduce its communication load.
One embodiment is a method performed by a CHF of a communication network. The method includes the CHF determining a payload size limit to be applied by a Charging Trigger Function (CTF) with respect to payload portions of messages sent to the CHF by the CTF, generating a message for the CTF, indicating the payload size limit, and sending the message towards the CTF.
Another embodiment comprises a network node configured for operation as a CHF of a communication network. The network node includes communication interface circuitry configured to exchange charging-related signaling with a network node operating as a CTF in the communication network, and processing circuitry. The processing circuitry is configured to determine a payload size limit to be applied by the CTF with respect to payload portions of messages sent to the CHF by the CTF, generate a message for the CTF, indicating the payload size limit, and send the message towards the CTF.
Another embodiment comprises a method performed by a CTF of a communication network. The method includes the CTF receiving a message from a CHF of the communication network, the message indicating a payload size limit to be applied by the CTF with respect to payload portions of messages sent to the CHF by the CTF. Further, the method includes the CTF limiting payload sizes of one or more messages sent towards the CHF by the CTF, according to the payload size limit.
Yet another embodiment comprises a network node configured to operate as a CTF in a communication network. The network node includes communication interface circuitry configured to exchange charging-related signaling with a network node operating as a CHF in the communication network, and further includes processing circuitry. The processing circuitry is configured to receive a message from the CHF, the message indicating a payload size limit to be applied by the CTF with respect to payload portions of messages sent to the CHF by the CTF, and limit payload sizes of one or more messages sent towards the CHF by the CTF, according to the payload size limit.
Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.
The maximum payload of charging messages going from a Network Function (NF) in a communication network to a supporting Charging Function (CHF) is sixteen million octets, i.e., 64 MB, with that limit being consistent with Hyper Text Transfer Protocol (HTTP) payload limits. Avoiding exceeding the maximum payload for charging messages sent towards the CHF from the Charging Trigger Functions (CTFs) implemented in given NFs prevents the receiving CHF from responding with “413 Request Entity Too Large”. See Clause 4.9.6 of 3GPP TS 29.501 for related details. Example NFs with CTFs include any one or more of Session Management Functions (SMFs), Network Exposure Functions (NEFs), Short Message Service Functions (SMSFs), and Charging Enablement Functions (CEFs).
However, beyond the built-in limit of 64 MB for message payloads, a CHF operating according to existing specifications has no mechanism for imposing lower, tailored limits on the maximum payload size. Recognized herein is that providing such control to the CHF offers an efficient mechanism for the CHF to limit the amount of information incoming to it from one or more CTFs in any given interval of time. Another advantage offered by the disclosed techniques is that implementation does not require undue complexity and complements rather than disrupts established approaches to CTF/CHF signaling.
Configuring a CHF to signal dynamically-determined limits on the payload of one or more messages sent to it by a CTF allows the CHF to strike a balance between the number of messages sent or the frequency message transmission versus the processing and storage demands associated with processing the payloads of incoming messages. That is, commanding smaller message payloads may tend to increase the number of individual messages sent from the CTF, which increases the “communications” load at the CHF, whereas allowing larger message payloads, e.g., up to some predefined upper limit, tends to decrease the number of messages generated and sent by the CTF, at the expense of obligating the CHF to process larger message payloads in the requisite processing windows and, potentially, obligating the CHF to store larger amounts of processed data.
One solution disclosed herein defines a new “trigger” that prompts a CTF to send a charging-related message towards a CHF, when the amount of information to be included in the message—i.e., the message payload-reaches a payload size limit indicated to the CTF by the CHF via signaling. Here, the size limit may refer to uncompressed payloads, or the size limit may refer to compressed payloads, e.g., a limit to be observed by the CTF with respect to payloads compressed using “gzip” or the like. In one or more embodiments, the CHF sends a message to the CTF that indicates at least one of a size limit for payloads transmitted without compression, a size limit before compression for payloads transmitted with compression, and a size limit after compression for payloads transmitted with compression. Correspondingly, the CTF observes the indicated size limit(s) for one or more charging messages sent by it towards the CHF.
Such arrangements make it possible for the CHF to control the size and the frequency of charging messages sent from a CTF. The CHF may signal payload size limits for a particular charging event or for some number of related charging events. In one or more embodiments, the CHF explicitly or implicitly indicates a scope of applicability for a payload size limit, and that indication allows the CHF to know whether the size limit is to be imposed with respect to messages relating to a single charging event, or all related charging events, or to all charging events involving a given subscriber or subscribers, or to all charging events relating to a given service or type of service. The dynamic size limit may be “turned on” and “turned off” by the CHF, either globally at the CTF, or with respect to particular charging events or types of charging events.
CTFs 14 report chargeable activities of subscribers to the CHF 16. “Subscriber” has broad meaning herein, denoting some type of User Equipment (UE) that is authorized to use the network 10 and is linked or otherwise associated with some kind of chargeable account or credit store that is used in authorizing or charging communication-service sessions or events involving the UE.
Chargeable activities may involve event-based communication services or session-based communication services and may involve services charged on an online basis—as they are consumed—or charged on an offline basis—post consumption. These chargeable activities comprise or cause “charging events” to occur at the CTFs 14, where a “charging event” is any event at a CTF 14 that requires or triggers the CTF 14 to send a charging-related message towards the CHF 16.
For example, a subscriber initiating use of a communication service subject to session-based online charging is a charging event that triggers the CTF 14 to send a Charging Request towards the CHF 16, requesting an initial authorization for starting the session. Continuation of the session requires the CHF 16 to send one or more further, intermediate Charging Requests, requesting continued authorization, with the termination of the session triggering one or more further Charging Requests to be sent by the CTF 14 towards the CHF 16.
A Charging Request may identify the subscriber, the communication service involved, and the type of charging that triggered the request. A Charging Request may also include a significant amount of other information, such as UE location, service-usage details and related logged information. However, as shown in the example embodiment of
The method 200 includes the CHF 16 determining (Block 202) a payload size limit to be applied by a CTF 14 with respect to payload portions of messages sent to the CHF 16 by the CTF 14, generating (Block 204) a message for the CTF 14, indicating the payload size limit, and sending (Block 206) the message towards the CTF 14.
Determining (Block 202) the payload size limit is performed, for example, in conjunction with the CHF 16 responding to a charging request message from the CTF 14, such that generating (Block 204) the message for the CTF 14 comprises generating a charging response message in reply to the charging request message. In one or more embodiments, or in one or more example instances of operation by the CHF 16, the charging request message is an initial charging request message sent from the CTF 14 for an initial charging event at the CTF 14. An “initial” charging event refers to charging that may involve multiple related events for the same subscriber, e.g., such as the initiation of a charging session for charging a session-based service.
In one or more other embodiments, or in one or more example instances of operation by the CHF 16, the charging request message is a subsequent charging request message sent from the CTF 14. Here, determining (Block 202) the payload size limit comprises re-determining the payload size limit with respect to a prior payload size limit indicated to the CTF 14 by the CHF 16, e.g., for any one or more of the same subscriber, or same session, or same service, or same service type. In other words, the CHF 16 may indicate a payload size limit to the CTF 14 and may expressly or implicitly indicate the scope of applicability of that payload size limit in terms of logical scope and/or temporal scope.
Temporal scope refers to whether the indicated payload size limit is good until canceled or expires after a certain time, unless refreshed. Logical scope refers to the chargeable events to which the indicated payload size limit is applied. For example, the chargeable events may be only those events involving a specific subscriber or even a specific charging session or specifically related charging events. On the other hand, an indicated payload size limit may have global scope—i.e., it is applied by the CTF 14 across chargeable events regardless of the particular subscriber(s) involved, at least for chargeable events relating to specific communication services or types of services—e.g., chargeable events related to multimedia streaming. In an example case, the scope is defined at the subscriber or User Equipment (UE) level, such that an indicated payload size limit applies to any number of services being used in parallel by the subscriber or UE, and the payload size limit may serve as a limit on aggregated payloads that involve charging data for more than one service.
A subsequent charging request message from the CTF 14 may include a trigger indication, indicating that the subsequent charging request message was triggered at the CTF 14 because of the prior payload size limit. Correspondingly, in one or more embodiments, the method 200 includes the CHF 16 re-determining the payload size limit responsive to the trigger indication.
One or more embodiments of the method 200 include the CHF 16 calculating the payload size limit in dependence on any one or more of: a service indicated by the CTF 14 in a charging request message sent by the CTF 14 to the CHF 16, profile information associated with a subscriber indicated in the charging request message, and load conditions at the CHF 16. Here, “load conditions” refers to “resource loading” at the CHF 16. Example resources are any one or more of communication-interface resources, computational resources, and storage resources.
Communication-interface resources refers to the overall message inflow/outflow bandwidth or messages-per-second capacity of the CHF 16. In an example embodiment, the CHF 16 chooses a relatively larger size limit for message payloads responsive to the loading on its communication interface reaching some defined threshold.
Computational resources refers to the message-processing resources of the CHF 16, such as what percentage of an overall message processing or computations-per-second processing capacity remain available at the CHF 16. In an example embodiment, the CHF 16 chooses a relatively smaller size limit for message payloads responsive to the loading on its computational resources reaching some defined threshold.
Storage resources refers to the memory or other storage space available to the CHF 16 for holding data from incoming charging-related messages and any associated processing results. In an example embodiment, the CHF 16 chooses a relatively smaller size limit for message payloads responsive to the loading on its storage resources reaching some defined threshold.
The CHF 16 may consider only one type of resource loading when deciding payload size limits or it may perform joint or weighted consideration of two or more types of resource loading when deciding payload size limits. Additionally, it may use different resource-loading thresholds for different subscribers or different services or service types, e.g., to reflect differing priorities regarding subscribers or services.
Broadly, determining (Block 202) the payload size limit comprises calculating the payload size limit as a function of prevailing load conditions at the CHF 16. The prevailing load conditions include a prevailing communication load at the CHF 16, in one or more embodiments, wherein determining (Block 202) the payload size limit comprises the CHF 16 setting the payload size limit to a relatively higher value, responsive to the prevailing communication load exceeding a defined communication load threshold. Here, “relatively larger” simply means that the CHF 16 chooses or calculates a payload size limit that is larger than it would have chosen or calculated if the communication load threshold were not exceeded.
The prevailing load conditions include a prevailing processing load at the CHF 16, in one or more embodiments, and determining (Block 202) the payload size limit comprises the CHF 16 setting the payload size limit to a relatively lower value, responsive to the prevailing processing load exceeding a defined processing load threshold. Here, “relatively lower” simply means that the CHF 16 chooses or calculates a payload size limit that is smaller than it would have chosen or calculated if the processing load threshold were not exceed.
As noted, determining (Block 202) the payload size limit comprises, in one or more embodiments, the CHF 16 determining a size limit for uncompressed payloads and determining a size limit for compressed payloads. Further, the message sent towards the CTF 14 by the CHF 16 to indicate the payload size limit also may indicate an applicability scope of the payload size limit. “Applicability scope” refers to the temporal or logical scope of the size limit, as explained above.
Receiving (Block 302) the message from the CHF 16 comprises, for example, the CTF 14 receiving a charging response message from the CHF 16, sent in response to a charging request message sent from the CTF 14 towards the CHF 16 for a charging event at the CTF 14. The charging request message comprises an initial charging request message, for example, sent for an initial charging event involving a subscriber.
The method 300 further includes, for example, the CTF 14 sending a subsequent charging request message towards the CHF 16, in response to payload information for a related or different charging event at the CTF 14 reaching the payload size limit. The subsequent charging request message indicates the payload size limit as a triggering basis. In other words, the payload size limit indicated by the CHF 16 defines a new trigger condition at the CTF 14, for triggering the CTF 14 to send a charging message towards the CHF 16.
The triggering condition may apply only to charging events that are related to the charging event for which the CHF 16 returned the payload size limit, or it may have broader applicability. Payload size limits may have limited applicability by default—e.g., a payload size limit indicated by the CHF 16 may by default apply only to related charging events—e.g., other charging events in the same charging session, or for the same subscriber, or for the same service or type of service, or any combination of such limitations. Alternatively, the default applicability may be broader, e.g., all charging events originating at the CTF 14 until the payload size limit expires or a new payload size limit is indicated. Of course, such broad applicability may still be tailored, e.g., by limiting application of the payload size limit only to the service or service type involved in the charging message that conveyed the payload size limit.
With such arrangements, the CTF 14 may operate with one broadly applied message payload size limit, or it may operate with different payload size limits applied for different subscribers and/or different services or service types. As such, at any given time, the CTF 14 may use different message payload size limits for different subscribers or services or may apply a message payload size limit to some charging messages sent towards the CHF 16 but not to others. The message from the CHF 16 that carries the payload size limit may include an indication indicating an applicability scope of the payload size limit, and that indication controls the temporal or logical scope of application of the message payload size limit at the CTF 14.
The size limit indicated by the CHF 16 may comprise size limits referring to any one or more of the uncompressed payload size, payload size before compression, and payload size after compression. Limiting (Block 304) the payload sizes of the one or more messages sent towards the CHF 16 by the CTF 14 in such circumstances comprises any one or more of such limits with respect to the payload(s) of one or more messages.
Further, the network node 20 includes processing circuitry 28 configured to determine a payload size limit to be applied by the CTF 14 with respect to payload portions of messages sent to the CHF 16 by the CTF 14, generate a message for the CTF 14, indicating the payload size limit, and send the message towards the CTF 14.
The processing circuitry 28 comprises fixed circuitry or programmatically-configured circuitry, or some mix thereof. In one or more embodiments, the processing circuitry 28 comprises one or more microprocessors that are specially adapted to operate as described herein for the processing circuitry 28, based on executing computer program instructions stored in storage 30, which comprises one or more types of computer-readable medium. The computer program instructions may be held as one or more computer programs (“CP(s)”) 32 held in the storage 30, which also may store one or more types of configuration data 34.
Determining the payload size limit is performed in conjunction with the CHF 16 responding to a charging request message from the CTF 14, for example. In such embodiments or instances of operation, the processing circuitry 28 generating the message for the CTF 14 comprises generating a charging response message in reply to the charging request message. The charging request message is an initial charging request message, for example, sent from the CTF 14, for an initial charging event at the CTF 14.
In other embodiments, or in other examples of operational circumstances, the charging request message is a subsequent charging request message sent from the CTF 14. Here, the processing circuitry 28 determines the payload size limit by re-determining the payload size limit with respect to a prior payload size limit indicated to the CTF 14 by the CHF 16. In at least one embodiment of the CHF 16 relevant to this example, the CHF 16 determines a payload size limit according to prevailing conditions or then-applicable considerations, and then later determines an updated size limit that modifies, overrides, or otherwise replaces that earlier-determined payload size limit, at least with respect to the scope of applicability of that earlier-determined payload size limit.
After the CHF 16 indicates a payload size limit to the CTF 14, that size limit defines a trigger condition at the CTF 14, i.e., for charging-related data governed by the payload size limit, the CTF 14 should not accumulate charging-related data in excess of the payload size limit.
Consequently, accumulating that amount of data triggers the CTF 14 to send a subsequent charging request message towards the CHF 16, with this subsequent charging message including a trigger indication, indicating that the subsequent charging request message was triggered at the CTF 14 because of the prior payload size limit. Correspondingly, the CHF 16 may re-determine the payload size limit in response to the trigger indication. That is, in response to receiving a charging-related message as a consequence of governed charging-related data at the CTF 14 reaching the size limit, the CHF 16 may recalculate the size limit on then-prevailing conditions or circumstances, meaning that the CHF 16 may maintain the prior size limit or modify it (where “modifying” includes canceling or removing it).
The processing circuitry 28 in at least one embodiment is configured to calculate a payload size limit in dependence on any one or more of: a service indicated by the CTF 14 in a charging request message sent by the CTF 14 to the CHF 16, profile information associated with a subscriber indicated in the charging request message, and load conditions at the CHF 16.
To determine a payload size limit, the processing circuitry 28 in one or more embodiments is configured to calculate the payload size limit as a function of prevailing load conditions at the CHF 16. The prevailing load conditions include, for example, a prevailing communication load at the CHF 16, where the processing circuitry 28 is configured to determine the payload size limit by setting the payload size limit to a relatively higher value, responsive to the prevailing communication load exceeding a defined communication load threshold. In the same embodiment or in another embodiment, the prevailing load conditions considered by the processing circuitry 28 include a prevailing processing load at the CHF 16, where the processing circuitry 28 is configured to determine the payload size limit by setting the payload size limit to a relatively lower value, responsive to the prevailing processing load exceeding a defined processing load threshold.
In embodiments where the processing circuitry 28 is configured to consider multiple factors, such as communication load and processing load, the processing circuitry 28 may be configured to perform a joint or weighted evaluation of the multiple factors based on priority or respective levels of loading, to determine a payload size limit. Broadly, the processing circuitry 28 may be configured to consider various types of loading or other prevailing circumstances when deciding the payload size limit and when deciding the applicability scope of the payload size limit. In at least one embodiment, policy information provided to the CHF 16 by a policy node in the communication network 10 defines various payload size limits to be used under certain circumstances or with respect to certain subscriber or certain services.
As noted, there may be a payload size limit determined for uncompressed payloads and a payload size limit determined for compressed payloads. Hence, when determining a payload size limit, the processing circuitry 28 in one or more embodiments is configured to express the size limit as two values: a size limit for uncompressed payloads and a size limit for compressed payloads. Also as noted, a message sent towards the CTF 14 by the CHF 16 that includes a payload size limit may also indicate an applicability scope of the payload size limit.
The example set 500 of processing modules includes a determining module 502 configured to determine a payload size limit to be applied by the CTF 14 with respect to payload portions of messages sent to the CHF 16 by a CTF 14, and a generating module 504 configured to generate a message for the CTF 14, indicating the payload size limit. Further, the example set 500 of processing modules includes a sending module 506 configured to send the message towards the CTF 14, and the CHF 16 may further include a receiving module 508 that is configured to receive messages from the CTF 14.
The network node 40 further includes processing circuitry 48 configured to receive a message from the CHF 16, the message indicating a payload size limit to be applied by the CTF 14 with respect to payload portions of messages sent to the CHF 16 by the CTF 14, and limit payload sizes of one or more messages sent towards the CHF 16 by the CTF 14, according to the payload size limit.
The processing circuitry 48 comprises fixed circuitry or programmatically-configured circuitry, or some mix thereof. In one or more embodiments, the processing circuitry 48 comprises one or more microprocessors that are specially adapted to operate as described herein for the processing circuitry 48, based on executing computer program instructions stored in storage 50, which comprises one or more types of computer-readable medium. The computer program instructions may be held as one or more computer programs (“CP(s)”) 52 held in the storage 50, which also may store one or more types of configuration data 54.
In one or more embodiments, the message received from the CHF 16 is a charging response message sent from the CHF 16 in response to a charging request message sent from the CTF 14 towards the CHF 16, for a charging event at the CTF 14. The charging request message may be an initial charging request message sent for an initial charging event involving a subscriber. The processing circuitry 48 may be configured to send a subsequent charging request message towards the CHF 16 in response to payload information for a related or different charging event at the CTF 14 reaching the payload size limit, the subsequent charging request message indicating the payload size limit as a message triggering basis.
The message from the CHF 16 regarding payload size limits may indicate a size limit for uncompressed payloads and a size limit for compressed payloads. In such embodiments, the processing circuitry 48 is configured to limit the payload sizes of the one or more messages sent towards the CHF 16 by the CTF 14 by limiting uncompressed payload sizes to the size limit indicated for uncompressed payloads and limiting compressed payload sizes to the size limit indicated for compressed payloads.
Further, in one or more embodiments, a message from a CHF 16 that indicates a payload size limit may also indicate an applicability scope of the payload size limit. Correspondingly, the processing circuitry 48 of the network node 40 in such embodiments is configured to apply (and not apply) the payload size limit in accordance with the indicated applicability scope.
The diagram shows three user devices 60-1, 60-2, and 60-3 merely as an illustrative example, with the devices denoted in the diagram using the label “USER DEV”. A greater or lesser number of user devices 60 may be active in the communication network 10 at any given time. The user devices 60 may also be referred to as user equipments or UEs.
The communication network 10 includes one or more Radio Access Networks (RANs) 66 that are based on one or more Radio Access Technologies (RATs), and further includes a Core Network (CN) 68 to provide access control, authorization, mobility management, and routing/coupling of user traffic to and from the external networks. In one or more example embodiments, the communication network is a 5G network, having a RAN 66 based on New Radio (NR) specifications and having a CN 68 based on 5G Core (5GC) specifications.
A charging system 70 includes a network node 20 that implements a CHF 16, where the charging system 70 comprises, for example, a converged charging system and couples to a billing system 72. In an example embodiment where the charging system 70 is a converged charging system for a 5G network, it includes additional functions beyond the CHF 16, such as an Account Balance and Management Function (ABMF), a Rating Function (RF), and a Charging Gateway Function (CGF).
A network node 40 in or associated with the CN 68 implements a NF 12 and an associated CTF 14 that sends charging-related messages towards the CHF 16.
Particularly, the CTF 14 generates charging request messages sent towards the CHF 16 and the CHF 16 returns corresponding charging response messages. As noted above, the CHF 16 may be associated with a RF 80 to rate the “cost” of service according to applicable tariffs, an ABMF 82 to manage user-account reservations and reconciliation for service authorization and account billing, and a CGF 84 for interfacing with the billing system 72. In the context of
The NF can be any functions in the 3GPP 5GC context. An example use case is the NF being a SMF, where the SMF contains a CTF that uses the charging services of a CHF, e.g., based on using the Nchf service interface defined for charging in 5G networks.
maxPayload
Uint64
This field contains maximum
payload before any
compression.
maxGzipPayload
Uint64
O
C
0 . . . 1
This field contains maximum
payload for the gzip
compression.
Proposed modifications to Table 6.1.6.3.6-1 in the same TS, which enumerates trigger types, appear below in italicized bold text:
MAX
—
PAYLOAD
The maximum size of the payload has
been reached.
The maxPayload should be read as being applicable both when the payload is sent compressed or uncompressed; it should be understood as the size before any compression is done or of the actual payload if there is not any compression. The new trigger category only creates a report if there is usage.
Notably, modifications and other embodiments of the disclosed invention(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention(s) is/are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SE2021/050705 | 7/9/2021 | WO |
