Patent Description:
Over time the number of products and services provided to users of telecommunication products has grown significantly. For example, in the early years of wireless communication, devices could be used for conversations and later also had the ability to send and receive text messages. Over time, technology advanced and wireless phones of varying capabilities were introduced which had access to various services provided by network operators, e.g., data services, such as streaming video or music service. More recently there are numerous devices, e.g., so called "smart" phones and tablets, which can access communication networks in which the operators of the networks, and other parties, provide many different types of services, applications, etc..

An example of how telecommunication services and products are provided to such devices will now be described with respect to a Charging and Billing system also known as an Online Charging System (OCS). In the OCS, the services that a customer can use, e.g., sending a Short Message Service (SMS) to another party or utilizing mobile data, is modelled as a service which is realized through a product specification and a product offering. A product offering is an item that a customer actually sees to purchase. This product offering can be a single product or a bundled product. Examples of single products include voice, data or SMS products. An example of a bundled service is an offering that allows <NUM> minutes of voice, <NUM> gigabytes (GB) of data and <NUM> SMS texts.

For any end user, there is a representation of the products and services within the OCS which can be in the form of an account that captures mapping of the assigned offerings with the actual resources that are allocated to an end user or subscriber.

In order to manage usage of services and to charge the customer based on the usage, an operator typically hosts an OCS in its network. This node or set of nodes is responsible for determining the requested usage, looking at the state of the account and making a determination of how much usage to grant to the user. This usage grant to the user can include the Granted Service Units (GSU) and a validity time (VT) for the GSUs. Additionally, not all available offerings are eligible for all usage requests, e.g., usage of a short message service (SMS) offering is not eligible for various data services. The procedure for determining which account resources are applicable for a particular service is referred to herein as resource selection and/or service selection.

Currently, there are standardized procedures for session charging with unit reservation, as shown for example in <NUM>rd generation partnership project (3GPP) technical specification (TS) <NUM> v <NUM>. <NUM> Figure <NUM>. <NUM>, which will now be described with respect to <FIG> shows a charging trigger function (CTF) which is located on a network node or network element <NUM> which interfaces with an end user (or another network element) for communicating with the OCS <NUM>. Initially, network element <NUM> receives a session initiation message, as shown in message <NUM>, which is initiated by either the user or another network element (not shown).

In order to perform a Reserve Units operation for a number of units, which can be monetary or non-monetary units, the network element <NUM> sends a credit control request (CCR) message <NUM> to the OCS <NUM>. The CCR message <NUM> includes a CC-Request-Type Attribute-Value-Pair (AVP) set to INITIAL_REQUEST. Additionally, if known, the network element <NUM> may include a Requested-Service-Unit (RSU) AVP (monetary or non-monetary units) in the request message <NUM>.

If the service cost information is not received by the OCS <NUM>, the OCS <NUM> determines the price of the desired service according to the service specific information received by issuing a rating request to a Rating Function. If the cost of the service is included in the request, the OCS <NUM> directly reserves the specified monetary amount and if the credit balance is sufficient, the OCS <NUM> reserves the corresponding amount from the user's account as represented by Perform Charging Control function <NUM>.

Once the reservation has been made, the OCS <NUM> returns a credit control answer (CCA) message <NUM> with CC-Request-Type set to INITIAL_REQUEST to the network element <NUM> in order to authorize the service execution (Granted-Service-Unit and possibly Cost-Information indicating the cost of the service and Remaining-Balance Attribute-Value-Pairs (AVP) are included). The OCS <NUM> may return the Validity-Time (VT) AVP with value field set to a non-zero value. The OCS <NUM> may also indicate in the Low-Balance-Indication AVP that the subscriber account balance has fallen below a predefined threshold of this account. Content and/or service delivery can then start and the reserved units are concurrently controlled.

During session delivery <NUM>, in order to perform Debit Units and subsequent Reserve Units operations, the network element <NUM> sends a CCR message <NUM> with CC-Request-Type AVP set to UPDATE_REQUEST, to report the units used and request additional units, respectively. The CCR message <NUM> is sent by the network element <NUM> between the INITIAL_REQUEST and TERMINATION_REQUEST either on request of the Credit-Control application within the validity time or if the validity time is elapsed. If known, the network element <NUM> may include Requested-Service-Unit AVP (monetary or non-monetary units) in the CCR message <NUM>. The Used-Service-Unit (USU) AVP is complemented in the CCR message <NUM> to deduct units from both the user's account and the reserved units, respectively.

During Perform Charging Control operation <NUM>, the OCS <NUM> deducts the amount used from the user's account. If the service cost information is not received by the OCS <NUM>, the OCS <NUM> determines the price of the desired service according to the service specific information received by issuing a rating request to a Rating Function. If the cost of the service is included in the request, the OCS <NUM> directly reserves the specified monetary amount. If the credit balance is sufficient, the OCS <NUM> reserves the corresponding amount from the user's account.

Once the deduction and reservation have been made, the OCS <NUM> returns a CCA message <NUM> with CC-Request-Type set to UPDATE_REQUEST to the network element <NUM> in order to allow the content and/or service delivery to continue (a new GSU AVP and possibly Cost-Information AVP indicating the cumulative cost of the service and Remaining-Balance AVP are included in the CCA message <NUM>). The OCS <NUM> may include in the CCA message <NUM>, the Final-Unit-Indication (FUI) AVP to indicate the final granted units. The OCS <NUM> may indicate in the Low-Balance-Indication AVP that the subscriber account balance has fallen below a predefined threshold of this account.

Session delivery <NUM> continues and the reserved units are concurrently controlled. At some point in time, the session is terminated, as represented by arrow <NUM>, at the network element <NUM>. When this occurs, the network element <NUM> sends a CCR message <NUM> with a CC-Request-Type AVP set to TERMINATION_REQUEST to terminate the active Credit-Control session and report the used units. The OCS <NUM> deducts the amount used from the account as represented by Perform Charging Control block <NUM>. Unused reserved units are released if applicable. The OCS <NUM> also acknowledges the reception of the CCR message <NUM> by sending CCA message <NUM> with CC-Request-Type AVP indicating TERMINATION_REQUEST (and possibly Cost-Information AVP indicating the cumulative cost of the service and Remaining-Balance AVP) to the network element <NUM>.

However, there are problems with the method described above with respect to <FIG> in that there is frequent signaling performed between the client (core network) and the OCS <NUM>. This frequent signaling has a capacity impact for both the client as well as the OCS <NUM>.

Quota determination can be a problem for a network operator to solve, since the allocation typically needs to be a careful compromise of competing factors. On one hand, the goal is to reduce network signaling by not having too many intermediate requests for additional service units but on the other hand the reduction of network signaling should not be at the expense of end user experience. That is, if too many units are allocated for one particular service as an initial service grant, then it might result in newer services or parallel services being denied more units and there may not be sufficient units for other services to consume. If too few units are initially allocated, then this can result in frequent signaling between the core network and the OCS <NUM> to obtain more units which can have a negative impact on processing capability in the network and or the OCS <NUM>.

<CIT> describes that in response to a credit control request, a PCCF identifies a mobile device for a data service and identifies the subscriber profile for the end user of mobile device. The subscriber profile for the end user indicates a QoS that is guaranteed to mobile device for data services. PCCF also identifies an account balance for the end user and rates the data service. <CIT> describes adaptive fine-grained fair usage control and similarly <CIT> describes fair usage enforcement in roaming packet-based access. 3GPP TS <NUM> version <NUM>. <NUM> describes Diameter charging applications for Digital cellular telecommunications system (Phase <NUM>+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE. One solution for optimizing this signaling is described in <CIT>. <CIT> describes embodiments relating to centralized unit determination that may be performed at a charging system, during the service unit granting process, in response to a request for service units received in association with an end user's charging session. However, the method associated with the signaling in <CIT> can require manual updates to the OCS <NUM> for each newly introduced offering. An example of this can be seen in <FIG>, in which a configuration <NUM> of the quota determination ruleset logic is shown which is required for each and every resource that shall be considered as quota determination input. Also, this quota configuration <NUM> is not executed by the OCS <NUM> only once. Instead, the configuration <NUM> is updated each time that new resources are configured in the OCS <NUM>. For example, <FIG> also shows how the configuration for Gift Social Package <NUM> was entered when this offering was introduced. Then, at another time, an entry was made for a similar offering, e.g., Social Plus Prepaid POS <NUM>, and a similar configuration entry was required to be manually entered by the operator.

Over time, these configurations keep on growing and the risk of manual errors when adding to the configuration increases. Deploying this technique has resulted in issues with configuration maintainability and extensibility since the configuration has to repeat the same logic for many offerings. This can lead to potentially undesirable large configurations. Additionally, when the same logic has been repeated many times, it takes more effort to update the logic in all applicable locations. From a performance perspective, the large configuration <NUM> can also result in a reduction in performance when the configuration has to be traversed each time a quota decision was needed. In other words, as the size of the configuration <NUM> grows, the amount of processing time for decision making increases which can decrease overall system performance.

Thus, there is a need to provide methods and systems that overcome the above-described drawbacks associated with respect to configurations and quota decisions for resource selection associated with products and/or services provided by an operator.

Embodiments allow for the reduction in the amount of time and effort required to update or generate a configuration when a new offering is introduced. In some scenarios, only a selection as to which quota determination rule should be applied for the new offering occurs. Additionally, when a service has been requested, only offerings that have been selected as being associated or applicable to the service need are processed by applying the quota determination rules. This can result in a simpler configuration of the quota determination ruleset logic as the logic does not need to consider if the offering would be applicable for the session or not, as that decision would already have been done in the previously performed resource selection step. In other words, the resources that are selected for rating (or reserving) are considered as an automatic input for quota determination.

The following description of the embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. The embodiments to be discussed next are not limited to the configurations described below, but may be extended to other arrangements as discussed later.

Reference throughout the specification to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with an embodiment is included in at least one embodiment of the present invention. Thus, the appearance of the phrases "in one embodiment" or "in an embodiment" in various places throughout the specification is not necessarily all referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

As described in the Background section, there are problems associated with current methods for performing quota decisions for resource selection associated with products and/or services provided by an operator. Embodiments described herein provide quota determination rules which are configured in the online charging system (OCS) with the rules being optionally attached to each offering when the offerings are configured in the OCS. These quota determination rules consider the resources associated each offering as an input. Prior to describing the various embodiments in detail, a simplified representation of the interactions between a network, an OCS and a provisioning system is now described with respect to <FIG>.

<FIG> shows the OCS <NUM>, a provisioning system <NUM> and a core network <NUM>. In this example, the provisioning system <NUM> is responsible for assigning or allocating resources to a subscriber provisioned in the OCS <NUM>. The core network <NUM> represents the nodes in an operator's system that are responsible for interacting with the OCS <NUM>, for requesting the units for consumption by the subscriber and for delivering services to end user devices (not shown). The OCS <NUM>, in this example, is responsible for allocating or granting units for consumption. Additionally, the OCS <NUM> is a communication node (or nodes) which is able to execute various embodiments described below with respect to quota determination.

Embodiments described herein connect the two distinct operations of resource and quota allocation such that optimization is achieved on the communication flows thereby resulting in optimized signaling. To achieve this, quota determination rules are configured in the OCS <NUM> and these quota determination rules may then be attached to each offering when these offerings are configured in the OCS <NUM>. As used herein, an offering describes an entity which has its own lifecycle and associated resources. An offering can be used to provide a service, e.g., voice or data for a more specialized service such as YouTube or Facebook. A quota as used herein defines an amount of granted service units (GSUs) and a validity time for using the GSUs, e.g., <NUM> gigabyte (GB) of data valid for <NUM> hour. Additionally, quota determination rules can be described as a ruleset including one or more rules associated with selecting a quota for an offering. As described herein, GSUs are the number of units granted for an interrogation in a session, i.e., the amount of resources that can be used until the next interrogation is sent towards the OCS <NUM>, and associated resources for an offering describes the amount of resources a subscriber has available for future use.

One trait of these quota determination rules is that several offerings often have a same wanted behavior for quota determination. Thus, it is an option to only configure certain rules once and then, for each offering with this similar behavior, to select the applicable quota determination rule. This allows for a shorter processing time associated with executing the quota determination rule associated with an offering as the size of the configuration is small as compared to conventional systems in which there is only a single, overly large configuration which is executed.

According to an embodiment, the quota determination rules are evaluated for each charging request that desires to reserve units. The offerings that are valid for the current request are selected and thereby only the rules that have been selected for a specific offering are evaluated. An offering may have one resource, e.g., <NUM> gigabyte (GB) of data, or several resources, e.g., <NUM> short message service (SMS) and <NUM> GB of data, associated with the offering. When evaluating a rule, all resources associated with the offering are accessible for the evaluation with the quota that is determined by the rule then being used as input for the rating phase.

According to embodiments, steps <NUM> and <NUM> associated with performing charging control as shown in <FIG>, can be altered in that resources that are selected for rating as a part of performing charging control can be automatically considered as input(s) to quota determination logic. This differs from conventional methods in that conventional methods do not include the capability of only considering selected resources as selected resources are not conventionally input to quota determination logic.

According to an embodiment, these selected resources can be aggregated, e.g., by total available balances or units for all selected offerings and resources, for quota determination logic to allocate a much larger quota if there is a significant amount of available funds. Allocating the GSUs can be based on the units that are provisioned to the subscriber from the provisioning system. As there is a possibility to aggregate the units on provisioned and selected resources automatically, this results in optimized signaling as the network is informed how and when to come back for the selected resources based on a dynamic algorithm for further reservation requests.

For example, consider that Offering A and Offering B are provisioned for a subscriber with <NUM> and <NUM> units, respectively. The GSUs can then be assigned based on the aggregated units, e.g., <NUM> units. This is an optimization in the way units are granted based on a dynamic algorithm that considers the provisioned resources on the account, as well as which resources are selected for the requested service.

According to an embodiment, a validity time for the GSUs can be allocated based on the expiration time of provisioned resources. As there is a possibility to consider several such provisioned resources, the validity time could effectively be set to the resource that is going to expire latest in time. This can result in an optimization of signaling as the validity time could be set to a later and dynamic time period. Additionally, the network need not request resources based on a fixed or static time period when the resources are not consumed already by the subscriber.

According to an embodiment, <FIG> shows how an offering can be modeled including how a quota determination rule can be connected to the offering. <FIG> shows an offering <NUM>, a definition block <NUM>, one or more resources <NUM> and the quota determination rule <NUM>. The offering <NUM> can include a start time <NUM> and an expiration time <NUM> which defines the time period during which the offering <NUM> is valid. The offering <NUM> is connected to a definition block <NUM> which includes the priority of the offering. The definition block <NUM> can also be connected to the quota determination rule <NUM> which includes one or more rules applicable for the offering <NUM>. Additionally, the offering <NUM> can be linked to one or more different resources <NUM>.

For example, looking at <FIG> in more detail, there can be an offering for the use of YouTube with the offering <NUM> being valid during calendar year <NUM> as shown by the start time <NUM> and the expiration time <NUM>. Additionally, the offering <NUM> selected when using YouTube can have the highest priority of all offerings (as shown in definition <NUM>) presented to ensure that the YouTube offering is consumed before a general data offering is used. This could be defined in the quota determination rule <NUM> which will be explained in more detail below. The resource <NUM> associated with this offering <NUM> is <NUM> GB of data.

According to an embodiment, a flow diagram <NUM> for performing charging in an OCS when a Credit-Control-Request (CCR) message is received, which can also use the quota determination logic described herein, will now be described with respect to <FIG>. Flow diagram <NUM> includes the steps of unit type determination <NUM>, resource selection <NUM>, quota determination <NUM> and rating <NUM>. During the unit type determination step <NUM>, the unit type, e.g., time, volume, and/or service specific units of the request is determined from parameters in the request. This is typically only performed for session setup, e.g., CC-Request-Type AVP set to INITIAL_REQUEST, and event charging, e.g., CC-Request-Type AVP set to EVENT_REQUEST. Additionally, the unit type is stored for the duration of the session.

During the resource selection step <NUM>, applicable offerings with connected resources, which can be one or more resources, are selected based on subscriber resources and parameters found in the request, e.g., for a Facebook data request all offerings that are applicable for Facebook data can be selected, which could include both a specific Facebook offering as well as a general data offering.

According to an embodiment, for each offering selected during the resource selection step <NUM>, a quota determination rule is applied to decide the applicable quota during step <NUM>. Since resource selection has previously been performed in step <NUM>, the quota determination step <NUM> knows the selected resources and then can apply quota determination logic based only on the resources applicable for this session for determining the quota. For example, there is no need in step <NUM> to consider any YouTube offerings when determining the quota for a Facebook session. Alternatively, the quota determination logic can use knowledge of the resources applicable for this session in conjunction with other information for determining the quota.

Based on the offerings selected in step <NUM> and the quota determined in step <NUM>, the rating of the request is then performed in step <NUM>. The rating step <NUM> reserves the quota specified in step <NUM> and allows the OCS to transmit a Credit-Control-Answer (CCA) back to the network. The CCA message typically includes at least granted service unit (GSU) information and a validity time associated with the offering.

According to an embodiment, a flow diagram <NUM> illustrating how quota determination for a plurality of offerings can be performed by an OCS will now be described with respect to <FIG>. Initially, the selected offerings, which include their associated resources, are sorted based on their priority in step <NUM>. The sorting is performed so that the order will be the same as the order used in the previously described rating step <NUM> of <FIG>. This sorting to obtain the same order of offerings is useful as it allows the offerings that will be used in the rating step <NUM> to decide the applicable quota.

In step <NUM>, a determination is made as to whether all of the offerings have been processed with respect to quota determination. If the outcome of step <NUM> is a no determination, then in step <NUM> a quota determination rule (or set of rules) is fetched for the current offering. In step <NUM>, the fetched quota determination rule is executed. A determination is then made in step <NUM> to know if the execution of the fetched quota determination rule finalized quota determination. If the determination is a no, then the process returns to step <NUM>.

If the outcome of the determination from either of steps <NUM> or <NUM> is a yes, then the process proceeds to step <NUM> which determines if a quota has been assigned. If a quota has been assigned, then the process shown in <FIG> is completed. If the outcome of step <NUM> is a no result, then a default quota configuration for the associated service is assigned and the process is considered to be completed. Default configurations can be stored based on the service, where the service is identified by the value of Service-Context-Id and Service-Identifier AVPs as defined in 3GPP TS <NUM>. According to an embodiment, the outcome of completing the process shown in <FIG> is then used as input to the rating step <NUM>.

According to embodiments, rulesets can be created for offerings. Rules could be configured, for example, in a programming language like Python or JavaScript or configured in a graphical rules editor. Examples of two different rulesets can be seen in <FIG> and <FIG>. <FIG> illustrates a sample ruleset to achieve an interrogation every two minutes when the consumption speed of data or a service is above <NUM> mebibytes (MiB)/s and the ruleset will default to grant <NUM> MiB valid for <NUM> minutes when the consumption speed is lower. A maximum GSU of <NUM> MiB or <NUM> MiB depending on the number of available units is also set, in this example, to make sure that a single service does not reserve all of the available service units. Additionally, the ruleset shown in <FIG> could be extended with more balance levels and with more levels of consumption speed.

Considering the ruleset <NUM> shown in <FIG> in more detail, in this example, consumption speed is the number of consumed units for the last interrogation divided by the length of the last interrogation. For a first interrogation, the consumption speed is considered to be zero and uses the default allocation of <NUM> MiB with a validity time of <NUM> minutes. Walking through the ruleset <NUM>, in the first step <NUM>, the process sums all available units for all selected offerings and if the sum total is above <NUM> gibibyte (GiB) proceed to decision step <NUM> else proceed to decision step <NUM>. Additionally, as previously described above, resources have been selected for each offering prior to implementing ruleset <NUM> so as to be used in the determination steps shown in <FIG>.

In step <NUM>, the consumption speed is determined. If the consumption speed is above <NUM> MiB/s quota determination is finalized and a <NUM> MiB grant with a validity time of <NUM> minutes is allowed as shown in block <NUM>. If the determination from step <NUM> is a no, then in step <NUM> it is determined if the consumption speed is less than <NUM> MiB/s. If the consumption is less than <NUM> MiB/s then quota determination is finalized and a grant of <NUM> MiB with a validity time of <NUM> is allowed as shown in block <NUM>. If the consumption is not less than <NUM> MiB/s then quota determination is finalized and a grant data amount of consumption speed * <NUM> with a validity time of <NUM> is allowed as shown in block <NUM>. Once any of blocks <NUM>, <NUM> or <NUM> is applied, i.e., finalized, no further quota rules are applied.

Returning to step <NUM>, if the sum of the total available units was determined to not be above <NUM> GiB then in step <NUM> it is determined if the consumption speed is above <NUM> MiB/s. If the consumption speed is above <NUM> MiB/s then quota determination is finalized and a <NUM> MiB grant with a validity time of <NUM> minutes is allowed, as shown in block <NUM>. In step <NUM>, if the consumption speed was determined to not be above <NUM> MiB/s then it is determined if the consumption speed is less than <NUM> MiB/s in step <NUM>. If the consumption speed is less than <NUM> MiB/s then quota determination is finalized and a <NUM> MiB grant with a validity time of <NUM> minutes is allowed as shown in block <NUM>. If the consumption speed is not less than <NUM> MiB/s then quota determination is finalized and a grant data amount of consumption speed * <NUM> with a validity time of <NUM> is allowed as shown in block <NUM>. Once any of blocks <NUM>, <NUM> or <NUM> is applied, i.e., finalized, no further quota rules are applied.

According to an embodiment, <FIG> shows an example of how another ruleset could look for a data offering. The goal of this example rule is to fully consume an offering before starting to use the next offering. This can be useful if a policy such as highspeed data is connected to the offering and the policy should switch at the same time as the offering is depleted, or if an end user notification should be sent directly when the offering has been consumed. Considering the ruleset <NUM>, in step <NUM> it is determined if the available units remaining for the current offering are above <NUM> MiB. If the available units remaining for the current offering is above <NUM> MiB, then quota determination is finalized and a <NUM> MiB grant with a validity time of <NUM> minutes is allowed as shown in block <NUM>. If the available units remaining for the current offering is not above <NUM> MiB, the proceed to the determination step <NUM> which determines if the available units remaining for the current offering is above <NUM> MiB.

If, from step <NUM>, it is determined that there are units remaining for the current offering, then then quota determination is finalized and a grant including the remaining units with a validity time of <NUM> minutes is allowed as shown in block <NUM>. If, in step <NUM>, it is determined that there are no units remaining for the current offering, then this ruleset <NUM> is completed and the next quota determination rule for the next selected offering is executed as previously described with respect to <FIG>, i.e., perform step <NUM> as applicable.

Embodiments allow for having and using a plurality of rulesets which are more tailored to various offerings as compared to using a single larger configuration which includes all rules and applying it to every offering. An example of the single larger configuration <NUM> was illustrated and described with respect to <FIG>. By way of contrast, <FIG> shows a more streamlined configuration of a quota determination rule <NUM> which, for example, would target new offerings using Facebook which indicates that this rule should be used for Facebook offerings and not all of the other options shown in the larger configuration <NUM>.

According to an embodiment there is a method for granting service units associated with a charging session for providing network service to an end user as shown in <FIG>. The method includes: in step <NUM>, receiving a request message for the network service; in step <NUM>, selecting one or more offerings associated with the received request message prior to applying quota determination rules, wherein each offering includes one or more associated resources; in step <NUM>, applying quota determination rules to the selected one or more offerings based on the associated resources; in step <NUM>, rating the service request based on the selected one or more offerings and the results of applying the quota determination rules, wherein the rating results in an assigned quota; and in step <NUM>, transmitting the assigned quota for the requested service, wherein the assigned quota includes the granted service units.

<FIG> illustrates a wireless network comprising a more detailed view of network node <NUM> and wireless device (WD) <NUM>, in support of various embodiments. These structural elements allow for the delivery of granted products and services to an end user, as well as, delivery of a request from an end user which triggers the execution of a configuration by the OCS <NUM>. For simplicity, <FIG> only depicts network <NUM>, network nodes <NUM> and 1100a, and WD <NUM>, i.e., a user equipment (UE). Network node <NUM> comprises processor <NUM>, storage <NUM>, interface <NUM>, and antenna 1101a. Similarly, WD <NUM> comprises processor <NUM>, storage <NUM>, interface <NUM> and antenna 1111a. These components may work together in order to provide network node and/or wireless device functionality, such as providing wireless connections in a wireless network. In different embodiments, the wireless network may comprise any number of wired or wireless networks, network nodes, base stations, controllers, wireless devices, relay stations, and/or any other components that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections.

Network <NUM> may comprise one or more IP networks, public switched telephone networks (PSTNs), packet data networks, optical networks, wide area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices. Additionally, an OCS <NUM> and core network (CN) <NUM> are shown.

Network node <NUM> comprises processor <NUM>, storage <NUM>, interface <NUM>, and antenna 1101a. These components are depicted as single boxes located within a single larger box. In practice however, a network node may comprise multiple different physical components that make up a single illustrated component (e.g., interface <NUM> may comprise terminals for coupling wires for a wired connection and a radio transceiver for a wireless connection). As another example, network node <NUM> may be a virtual network node in which multiple different physically separate components interact to provide the functionality of network node <NUM> (e.g., processor <NUM> may comprise three separate processors located in three separate enclosures, where each processor is responsible for a different function for a particular instance of network node <NUM>). Similarly, network node <NUM> may be composed of multiple physically separate components (e.g., a NodeB component or gNB component and a RNC component, a BTS component and a BSC component, etc.), which may each have their own respective processor, storage, and interface components. In such a scenario, each unique NodeB and BSC pair, may be a separate network node. In such embodiments, some components may be duplicated (e.g., separate storage <NUM> for the different RATs) and some components may be reused (e.g., the same antenna 1101amay be shared by the RATs).

Processor <NUM> may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node <NUM> components, such as storage <NUM>, network node <NUM> functionality. For example, processor <NUM> may execute instructions stored in storage <NUM>. Such functionality may include providing various wireless features discussed herein to wireless devices, such as WD <NUM>, including any of the features or benefits disclosed herein.

Storage <NUM> may comprise any form of volatile or non-volatile computer readable memory including, without limitation, persistent storage, solid state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. Storage <NUM> may store any suitable instructions, data or information, including software and encoded logic, utilized by network node <NUM>. Storage <NUM> may be used to store any calculations made by processor <NUM> and/or any data received via interface <NUM>.

Network node <NUM> also comprises interface <NUM> which may be used in the wired or wireless communication of signaling and/or data between network node <NUM>, network <NUM>, and/or WD <NUM>. For example, interface <NUM> may perform any formatting, coding, or translating that may be needed to allow network node <NUM> to send and receive data from network <NUM> over a wired connection. Interface <NUM> may also include a radio transmitter and/or receiver that may be coupled to or a part of antenna 1101a. The radio may receive digital data that is to be sent out to other network nodes or WDs via a wireless connection. The radio may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 1101a to the appropriate recipient (e.g., WD <NUM>).

Antenna 1101a may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In some embodiments, antenna 1101a may comprise one or more omni-directional, sector or panel antennas operable to transmit/receive radio signals between, for example, <NUM> and <NUM>.

WD <NUM> may be any type of wireless endpoint, mobile station, mobile phone, wireless local loop phone, smartphone, user equipment, desktop computer, PDA, cell phone, tablet, laptop, VoIP phone or handset, which is able to wirelessly send and receive data and/or signals to and from a network node, such as network node <NUM> and/or other WDs via uplink signals or sidelink signals, respectively. WD <NUM> comprises processor <NUM>, storage <NUM>, interface <NUM>, and antenna 1111a. Like network node <NUM>, the components of WD <NUM> are depicted as single boxes located within a single larger box, however in practice a wireless device may comprises multiple different physical components that make up a single illustrated component (e.g., storage <NUM> may comprise multiple discrete microchips, each microchip representing a portion of the total storage capacity).

Processor <NUM> may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in combination with other WD <NUM> components, such as storage <NUM>, WD <NUM> functionality. Such functionality may include providing various wireless features discussed herein, including any of the features or benefits disclosed herein.

Storage <NUM> may be any form of volatile or non-volatile memory including, without limitation, persistent storage, solid state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. Storage <NUM> may store any suitable data, instructions, or information, including software and encoded logic, utilized by WD <NUM>. Storage <NUM> may be used to store any calculations made by processor <NUM> and/or any data received via interface <NUM>.

Interface <NUM> may be used in the wireless communication of signalling and/or data between WD <NUM> and network node <NUM>. For example, interface <NUM> may perform any formatting, coding, or translating that may be needed to allow WD <NUM> to send and receive data from network node <NUM> over a wireless connection. Interface <NUM> may also include a radio transmitter and/or receiver that may be coupled to or a part of antenna 1111a. The radio may receive digital data that is to be sent out to network node <NUM> via a wireless connection. The radio may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna 1111a to network node <NUM>.

Antenna 1111a may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In some embodiments, antenna 1111a may comprise one or more omni-directional, sector or panel antennas operable to transmit/receive radio signals between <NUM> and <NUM>. For simplicity, antenna 1111a may be considered a part of interface <NUM> to the extent that a wireless signal is being used.

The non-limiting term UE refers to any type of wireless device communicating with a network node in a cellular or mobile communication system over radio interface. Examples of UEs are target devices, device to device (D2D) UEs, proximity-based service (ProSe) UEs, machine type UEs or UEs capable of machine to machine communication (aka category <NUM> UEs, low cost and/or low complexity UEs), PDAs, iPADs, tablets, mobile terminals, smart phones, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB dongles, wireless devices etc. An example of a UE <NUM> is illustrated in <FIG> including a processor <NUM>, radio transceiver <NUM>, and antenna <NUM>.

Various embodiments described herein refer in some fashion to nodes, e.g., OCS <NUM>. In some embodiments the non-limiting network node (also interchangeably called as node) is more commonly used and it refers to any type of network node which directly or indirectly communicates with the UE. It can be radio network node or a node in the core network <NUM> or fixed part of the network such as the OCS <NUM>. For example, it can be a network node serving the UE, a network node neighboring to the serving network node of the UE, any network node in the radio network or in the core network in wireless communication system in which UE operates. Examples of network nodes are base stations (BS), multi-standard radio (MSR) radio nodes such as MSR BS, eNode B (eNB), network controllers, radio network controllers, base station controllers, relay, donor node controlling relays, base transceiver stations (BTS), access points (AP), core network nodes (e.g. MSC, MME etc), O&M, OSS, SON, location server (e.g. E-SMLC), MDT etc. It is to be understood that network node/OCS <NUM> includes functional pieces similar to those shown for base station <NUM>.

Embodiments as described herein allow for the configuration used to introduce a new offering can be greatly reduced in size and effort, as in conventional systems each new offering required an update to the quota determination configuration. Instead, in some cases, embodiments allow for only selecting which quota determination rule should be applied to a new offering. Additionally, only the offerings that have been selected for the service is applicable for quota determination. This results in simpler configuration of the quota determination logic since it does not need to consider if the offering would be applicable for the session or not, that have instead already been performed by the same resource selection step that selects offerings applicable for rating. Embodiments also allow for resources that are associated with an offering are considered as automatic input for quota determination. Embodiments described herein can be executed at the OCS <NUM>.

According to an embodiment, there is a method to connect the provisioned offerings with the quota determination mechanism in order to optimize the signaling between client, e.g., core network <NUM>, and the OCS <NUM>. This connection of provisioned resources with quota determination is dynamic and automatic in nature so as to result in much lesser configuration work and also to bring dynamicity to the value assigned to GSUs and validity time attribute-value-pairs (AVPs).

The disclosed embodiments provide methods and devices for performing quota decisions for resource selection associated with products and/or services provided by an operator. It should be understood that this description is not intended to limit the invention. On the contrary, the embodiments are intended to cover alternatives, modifications and equivalents, which are included in the scope of the invention as defined in the appended claims. Further, in the detailed description of the embodiments, numerous specific details are set forth in order to provide a comprehensive understanding of the claimed invention. However, one skilled in the art would understand that various embodiments may be practiced without such specific details.

As also will be appreciated by one skilled in the art, the embodiments may take the form of an entirely hardware embodiment or an embodiment combining hardware and software aspects. Further, the embodiments, e.g., the configurations and other logic associated with quota determination rules to include embodiments described herein, such as, the method associated with <FIG>, may take the form of a computer program product stored on a computer-readable storage medium having computer-readable instructions embodied in the medium. Any suitable computer-readable medium may be utilized, including hard disks, CD-ROMs, digital versatile disc (DVD), optical storage devices, or magnetic storage devices such as floppy disk or magnetic tape. Other non-limiting examples of computer-readable media include flash-type memories or other known memories.

Claim 1:
A method for granting service units associated with a charging session for providing network service to a subscriber or end user, the method comprising the steps of
receiving (<NUM>) a request message for the network service;
selecting (<NUM>) one or more offerings associated with the received request message prior to applying quota determination rules, wherein each offering includes one or more associated resources;
applying (<NUM>) quota determination rules to the selected one or more offerings based on the associated resources;
rating (<NUM>) the network service request based on the selected one or more offerings and the results of applying the quota determination rules, wherein the rating results in an assigned quota;
transmitting (<NUM>) the assigned quota for the requested network service, wherein the assigned quota includes the granted service units;
characterized in that the step of selecting further comprises selecting the one or more offerings from a plurality of offerings, based on subscriber resources and parameters found in the request message, wherein each offering is a product offering provisioned for a subscriber.