WO2020074101A1

WO2020074101A1 - Methods and systems for performing rerating of subscriber records through selective processing

Info

Publication number: WO2020074101A1
Application number: PCT/EP2018/077928
Authority: WO
Inventors: Björn BJÖRKLUND; Gustav ÅKESSON; Magnus Lindström; Rolf Svensson; Robert TÖRNKVIST
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2018-10-12
Filing date: 2018-10-12
Publication date: 2020-04-16
Also published as: EP3864604A1

Abstract

Systems and methods are provided for rerating subscriber usage event records associated with services. The method includes: identifying a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger; identifying a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and rerating the subscriber usage events in the identified first and second subsets.

Description

METHODS AND SYSTEMS FOR PERFORMING RERATING OF SUBSCRIBER

RECORDS THROUGH SELECTIVE PROCESSING

TECHNICAL FIELD

[0001] The present invention generally relates to communication networks and, more particularly, to mechanisms and techniques for rerating of subscriber records.

BACKGROUND

[0002] 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.

[0003] 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), which may be a part of an operators Business Support System (BSS). 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 500 minutes of voice, 50 gigabytes (GB) of data and 200 SMS texts.

[0004] 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.

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

[0006] In order to perform a Reserve Units operation for a number of units, which can be monetary or non-monetary units, the network element 100 sends a credit control request (CCR) message 106 to the OCS 102. If the service cost information is not received by the OCS 102, the OCS 102 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 102 directly reserves the specified monetary amount and if the credit balance is sufficient, the OCS 102 reserves the corresponding amount from the user’s account as represented by Perform Charging Control function 108.

[0007] Once the reservation has been made, the OCS 102 returns a credit control answer (CCA) message 12 to the network element 100 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 102 may return the Validity-Time (VT) AVP with value field set to a non-zero value. The OCS 102 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.

[0008] During session delivery 1 12, in order to perform Debit Units and subsequent Reserve Units operations, the network element 100 sends a CCR message 1 14 to report the units used and request additional units, respectively. The CCR message 114 is sent by the network element 100 between an INITIAL_REQUEST message and a TERMINATION_REQUEST message either on request of the Credit- Control application within the validity time or if the validity time is elapsed. If known, the network element 100 may include Requested-Service-Unit AVP (monetary or non- monetary units) in the CCR message 1 14. The Used-Service-Unit (USU) AVP is complemented in the CCR message 1 14 to deduct units from both the user’s account and the reserved units, respectively.

[0009] During Perform Charging Control operation 1 16, the OCS 102 deducts the amount used from the user’s account. If the service cost information is not received by the OCS 102, the OCS 102 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 102 directly reserves the specified monetary amount. If the credit balance is sufficient, the OCS 102 reserves the corresponding amount from the user’s account.

[0010] Once the deduction and reservation have been made, the OCS 102 returns a CCA message 1 18 with CC-Request-Type set to UPDATE_REQUEST to the network element 100 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 1 18). The OCS 102 may indicate in the Low-Balance-Indication AVP that the subscriber account balance has fallen below a predefined threshold of this account.

[0011] Session delivery 1 12 continues and the reserved units are concurrently controlled. At some point in time, the session is terminated, as represented by arrow 120, at the network element 100. When this occurs, the OCS 4 deducts the amount used from the account. Unused reserved units are released if applicable.

[0012] As described above, there is a Rating Function associated with the OCS 102. The core of the rating process is to assign a price to usage. The price is typically based on information, such as, usage details, which products the subscriber or subscribers have assigned to them, balances and accumulations, thresholds and the like. As part of the rating process, accumulations are typically updated and event data is generated for processing of downstream systems, for example, billing and invoicing. The online rating process can also impact real-time policy decisions towards the packet core network, including service barring or quality of service (QoS) changes. For example, policy decisions resulting in lower or higher data consumption speed for an end user.

[0013] Rating is a complex process, relying on multiple sources of data and configuration, and if mistakes are made, for example when assigning an incorrect price per minute for a voice call offering, operators typically require a mechanism that allows the operators to correct the mistake. For example, a mechanism to correct the price and rerun the rating process as exactly as possible, i.e., to perform a rerating. When a problem is identified the root cause is corrected and the set of previously rated and charged events are processed again, i.e., they are rerated.

[0014] Thus, rerating is a business support function where previously rated usage and charges are re-processed again with the intent of reaching a different result.

Rerating is typically performed by selecting all subscribers belonging to a particular time period, such as a bill cycle instance, e.g., the month of May, and to reprocess/rerate all previously rated events for all of the subscribers belonging to that time period or bill cycle instance. A general overview of a conventional rerating process is now described with respect to Figure 2.

[0015] Initially a charging or billing problem has been identified and, in step 202, it is determined that a potential situation for rerating exists. In step 204, a node in the OCS 102 sorts all events into a file. Then, in step 206, all of the events in the file are rated, followed by, in step 208 a rerating and updating of all events. The rerating process ends with the generation of an end statement and applying the result to all affected customer accounts in step 210.

[0016] Due to the nature of existing techniques for rerating, rerating is resource intensive as each rerate of an event needs to decode and parse the input record, rate it, create a new output record and create a new charge. All of these processing steps for numerous records, particularly when performed over numerous subscribers, generates a large set of data and records that need to be versioned, tracked, stored and processed during billing. This becomes an even larger problem for shared accounts and hierarchies in, for example a company or corporation, where one impacted usage record can require updating millions of records for thousands of subscribers after a rerate.

[0017] One option for reducing the quantity of records processed during a rerate procedure would be to do a partial rerate through manual selection of records.

However, since this partial rerate is manual instead of automatic, it can have an undesirably high risk of introducing further errors, such as, missing dependencies which will cause inconsistent and/or incorrect data in the rerated records.

[0018] Furthermore, the existing techniques also introduce the problem of rerating subscribers which might not be affected by the corrected mistake at all. For example, if the rerating is triggered by a price change of a roaming offering, there would be no reason to rerate subscribers who are not eligible for roaming services, or are eligible for the roaming service but have not used them during the selected time period. [0019] Thus, there is a need to provide methods and systems that overcome the above-described drawbacks associated with rerating subscriber records.

SUMMARY

[0020] Embodiments allow for rerating a subset of subscriber records to reduce time and cost involved with rerating. This in turn provides for optimized updates of financial transaction records and account/product related resources based on an analysis of what resources are actually affected by using the rerating embodiments described herein.

[0021] According to an embodiment, there is a method for rerating subscriber usage event records associated with services. The method includes: identifying a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger; identifying a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and rerating the subscriber usage events in the identified first and second subsets.

[0022] According to an embodiment, there is a system for rerating subscriber usage event records associated with services. The system including: at least one network node with at least one processor configured to: identify a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger; identify a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and rerate the subscriber usage events in the identified first and second subsets.

[0023] According to an embodiment, there is a computer-readable storage medium containing a computer-readable code that when read by a processor causes the processor to perform a method for are provided for rerating subscriber usage event records associated with services. The method includes: identifying a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger; identifying a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and rerating the subscriber usage events in the identified first and second subsets.

[0024] According to an embodiment, there is an apparatus adapted to a identify a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger; identify a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and rerate the subscriber usage events in the identified first and second subsets.

[0025] According to an embodiment, there is an apparatus including: a first module configured to identify a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger; a second module configured to identify a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and a third module configured to rerate the subscriber usage events in the identified first and second subsets.

BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings:

[0027] Figure 1 illustrates steps associated with session charging with unit reservation per 3^rd generation partnership project (3GPP) technical specification (TS) 32.299;

[0028] Figure 2 shows an example of a conventional rerating process;

[0029] Figure 3 illustrates interactions between customers/subscribers, a business support system (BSS) and a core network according to an embodiment;

[0030] Figure 4 depicts a record set, including subsets, according to an embodiment;

[0031] Figure 5 shows a flowchart of a rerating process according to an embodiment;

[0032] Figure 6 shows an event impact graph including records according to an embodiment;

[0033] Figure 7 shows a flowchart of a method for rerating according to an embodiment;

[0034] Figure 8 depicts a communication node in communication with other communication nodes according to an embodiment; and

[0035] Figure 9 depicts an electronic storage medium on which computer program embodiments can be stored. DETAILED DESCRIPTION

[0036] 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.

[0037] 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.

[0038] As described in the Background section, there are problems associated with traditional systems and methods which perform rerating of subscriber records. Embodiments described herein provide systems and methods for rerating subscriber records which address these problems. For example, according to an embodiment, the rerating process is divided into multiple passes through the data, in order to select only the subscribers and events which are actually affected by the issue which initiated the rerating process. The initial pass through the data determines which subscribers and records need to be rerated directly as a result of the issue, which issue is also referred to herein as“the primary rerating reason”. For example, a primary rerating reason could be, e.g., a correction of an incorrect voice service price. In this case, the initial pass would identify those subscribers who are directly impacted by the incorrect voice service price.

[0039] A second pass through the data builds a dependency graph of subscribers and events in order to identify which other subscriber records to include in a particular rerate process, i.e., in addition to those subscribers and records that were already identified in the initial pass. For example, when a price change for subscriber A affects the charges on another subscriber B, e.g., which subscribers are in a shared account relationship, the second pass could operate to include subscriber B in the dependency graph for inclusion in the set to be rerated. As another example, the second pass could determine that a price change for usage X (the primary rating reason) indirectly affects usage Y (which was originally not identified as a primary rerating reason), thereby resulting in the inclusion of other subscribers that are indirectly affected by the primary rating reason.

[0040] The third and final pass through the data performs actual rerating of the identified subset of subscriber records. Systems and methods for implementing various embodiments are described below after a brief description of a business support system (BSS) which can interact with the various embodiments is described.

[0041] Figure 3 shows an operator network 300 which includes a core network 302 and a business support system (BSS) 304, with various elements of the operator network 300 being in communications with various customers and subscribers 306. The BSS 304 includes the online charging system (OCS) 308 which has a revenue management node 310. The BSS 304 is a group of functions which can be spread out over a plurality of nodes to include, but not limited to, charging logic, routing logic, a subscriber database, and subscriber distribution controller(s) (SDC). The core network 302 represents the nodes in an operator’s system that are responsible for interacting with the OCS 308 in the BSS 304, for requesting the units for consumption by the subscriber and for delivering services to end user devices. The OCS 308, in this example, is responsible for allocating or granting units for consumption.

Additionally, the revenue management node 310 is a communication node (or nodes) which is able to execute various embodiments described below with respect to rerating.

[0042] As described above, the rerating process is invoked to rerun business logic after changes have been made with the intent of obtaining different results, e.g., a price change which alters an account balance can be made during the rerating process. Embodiments allow for avoiding updating all event records by default, by determining which events will be rated differently during rerating as compared to the original rating process. Subscriber records that need to be updated include two types of records: (1 ) records which are rerated as a direct result of the change, also referred to herein as the primary rerating reason, and (2) records that are rerated due to resource dependencies, also referred to herein as the secondary rerating reason.

Both types of subscriber records can be identified using automatic detection

processes.

[0043] As described above, embodiments avoid the updating of all of the event or subscriber records by default when performing a rerating process. A representation of the sets of records associated with rerating is now described with respect to Figure 4. In Figure 4, there is a set 400 representing the entire set of records for a subscriber in a period of time. There is a subset of primary records 402, a subset of secondary records 404 and the remaining records 406 of the records set 400. The subset of primary records 402 are records associated with the primary reason for rerating, i.e. , records which are to be rerated as a direct result of the change which was made in the OCS 308 and which were identified in the initial pass. The subset of secondary records 404 are records associated with the secondary reason for rerating, i.e., records which are to be rerated due to resource dependencies and which were identified in the second pass. The remaining records 406 are those records which need not be rerated since they were not identified in either the initial or secondary pass through the set 400.

[0044] To further illustrate these embodiments, five examples of non-limiting categories of primary rerating reasons that resulted in OCS 308 changes that can impact the outcome of the rating process are now described. A first category includes backdated changes to one or more business configurations. If business rules or characteristics of a Product Offering (PO) have changed with backdating to, for example, correct a fault in the previous version of the configuration, events rated using the previous version may need to be rerated. A second category includes changes to customer data. For example, when provisioned customer or product data has been changed due to backdating, either to correct a fault in the customer data or as a business decision to give access to a product before the time of purchase, events rated against the previous customer and/or product data may need to be rerated.

[0045] A third category includes backdated changes to network input data. For example, if some network events have been updated for correcting network data, the updated events may need to be rerated. A fourth category includes events which have been cancelled. For example, when network events have been marked to be removed from the rating process, this can trigger rerating due to resource

dependency. A fifth category includes events which have been reordered. For example, offline network events which have been processed in the wrong order can trigger rerating due to resource dependency.

[0046] According to an embodiment, rerating events impacted by the primary reason may also require rerating other impacted records for a secondary reason due to a dependency on common resources. For example, if a charging operation updates a resource, such as a balance or a counter with a changed value, then other charging requests using this counter typically need to be rerated as well. This also applies to shared resources which may trigger secondary rerating for other subscribers using the same shared resource.

[0047] According to an embodiment, resource evaluation is realized by comparing the original rated record with the rerated version of the same record with various possible annotations being added to the resource as will now be described. If a resource, e.g., a balance and/or a counter, is present in the rerated record but not in the original record, that resource can be marked as“Added”. If a resource is present in the original record but not in the rerated record, that resource can be marked as “Removed”. If a same resource is present in both the original and the rerated record, and the change or the resource balance is different, then that resource can be marked as“Affected”. If the same resource is present in both the original ant the rerated record, and the change or the balance is the same, then that resource can be marked as“Not Affected”.

[0048] According to an embodiment, if a resource is marked as“Removed”, “Added” or“Affected”, then all records that have a dependency to that resource are to be rerated from the start of the rerating session. When applying the results of the rerate the following can occur: resources marked“Removed” are to be removed, if present, from the rerated account; resources marked“Added” are to be added, if present, and initialized with the rerated balance; resources marked“Affected” are to have their balance replaced with the rerated balance; and other resources on the account are not updated.

[0049] According to an embodiment, a flowchart 500 illustrating an embodiment of the rerating process is now described with respect to Figure 5. Initially, in step 502, an automated detection of impacted products occurs and the customer(s) can determine an initial set of events to evaluate. In step 504, processing the initial set of events to determine which events are impacted by the primary rerating reason and creating an event impact graph occurs. In step 506, rating the initial set of events, comparing original and just rated initial set of events to determine resource

dependency and adding events with resource dependency to the event impact graph occurs. In step 508, rerating of events indicated by the event impact graph occurs and in step 510 updating resources as indicated by the resource dependency evaluation occurs. While the terms processing and rating are used in flowchart 500 to

differentiate the steps described in the flowchart 500, these steps are all a part of the rerating process and as such, the term rerating could be used in substitution for processing and rating.

[0050] According to an embodiment, steps 504, 506, 508 and 510 can be performed by the revenue management node 310 within the OCS 308. According to an alternative embodiment, one or more of steps 504, 506, 508 and 510 can be performed on one or more other nodes within the OCS 308 when implementing embodiments in some legacy systems, e.g., a service delivery platform (SDP) node, as well as other billing and revenue management systems.

[0051] According to an embodiment, an example of the event impact graph, as well as the various records subsets is now described with respect to Figure 6. In this example, Figure 6 shows the event impact graph 600 when rerating is initiated due to a backdated configuration change of a Product Offering (PO), which is the output of step 504 of Figure 5 (also examples of the outputs of steps 506, 508 and 510 are shown in Figure 6). The primary rerating reason initiating this change can be seen by comparing the PO Version fields of UsageEvent 1 record 602 and UsageEvent T 604. More specifically, UsageEventl record 602 has a PO Version of 1 .1 and UsageEvent T record 604 has a PO Version of 1.2, i.e. , indicating that the PO was updating and thus triggering a rerating session. UsageEventl record 602 includes uses two resources, AccVoiceCost 606 and MainBalance 608 (which includes both

MainBalanceBefore and MainBalanceAfter) which are both updated in the rerating of the UsageEventl record 602 as can be seen in AccVoiceCost 610 and MainBalance 612 of UsageEventl’ record 604 which have different values than those resources of UsageEventl record 602. [0052] Associated with AccVoiceCost 606 and ManBalance 608 of UsageEventl 602, is UsageEvent2 618 which has its own versions of these resources AccVoiceCost 614 and ManBalance 616 (which includes both MainBalanceBefore and MainBalanceAfter) which are both updated in the rerating of the UsageEvent2 record 618 as can be seen in AccVoiceCost 622 and MainBalance 624 of UsageEvent2’ record 620 which have different values than those resources of UsageEvent2 record 602. This is an example of rerating due to the secondary rerating reason.

[0053] UsageEvent3 626 is triggered for rerating as UsageEvent3 626 includes the resource MainBalance. This can be seen by comparing the MainBalance 630 (which includes both MainBalanceBefore and MainBalanceAfter) of UsageEvent 626 with the MainBalance 632 of UsageEvent 3’ 628. This is another example of rerating due to the secondary rerating reason. Also shown in Figure 6 is UsageEvent4 636 which is identified as“Not Affected” as UsageEvent4 636 is neither impacted by a change PO version nor any shared resource from any other rerated record. Thus UsageEvent4 636 is not rerated.

[0054] According to an embodiment there is a method 700 for granting service units associated with a charging session for providing network service to an end user as shown in Figure 7. The method includes: in step 702, identifying a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger; in step 704, identifying a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and in step 706, rerating the subscriber usage events in the identified first and second subsets [0055] According to an embodiment, step 704 of Figure 7 can also include the steps of: rating the first subset of the subscriber usage event records to generate a new set of rated usage events; and comparing the new set of rated events to a previously performed rating of the first subset of subscriber usage event records; wherein the second subset of the subscriber usage event records includes those subscriber usage event records from the new set of rated usage events which have different resource values as compared to the previously performed rating of the first subset of subscriber usage event records

[0056] Embodiments described above can be implemented in one or more nodes (or servers). An example of such a group of communication nodes 800, which may be in a same physical location or distributed over different locations, is shown in Figure 8. The communication node 800 (or other network node) includes a processor 802 for executing instructions and performing the functions described herein, e.g., the functions associated with the rerating process. The communication node 800 also includes a primary memory 804, e.g., random access memory (RAM) memory, a secondary memory 806 which can be a non-volatile memory, and an interface 808 for communicating with other portions of a network or among various nodes/servers if, for example, the various functional modules are distributed over multiple servers.

[0057] Processor 802 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 communication node 800 components, such as memory 804 and/or 806, server 800 functionality. For example, processor 802 may execute instructions stored in memory 804 and/or 806.

[0058] Primary memory 804 and secondary memory 806 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, RAM, read-only memory (ROM), removable media, or any other suitable local or remote memory component. Primary memory 804 and secondary memory 806 may store any suitable instructions, data or information, including software and encoded logic, utilized by node 800. Primary memory 804 and secondary memory 806 may be used to store any calculations made by processor 802 and/or any data received via interface 808.

[0059] Communication node 800 also includes interface 808 which may be used in the wired or wireless communication of signaling and/or data. For example, interface 808 may perform any formatting, coding, or translating that may be needed to allow

communication node 800 to send and receive data over a wired connection. Interface 808 may also include a radio transmitter and/or receiver that may be coupled to or a part of the antenna. The radio may receive digital data that is to be sent out to other network nodes or wireless devices 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 an antenna to the appropriate recipient.

[0060] According to an embodiment, the methods described herein can be implemented on one or more communication nodes 800 with these nodes 800 being located within the OCS 308 or distributed in a cloud architecture associated with the operator network 300. Cloud computing can be described as using an architecture of shared, configurable resources, e.g., servers, storage memory, applications and the like, which are accessible on-demand. Therefore, when implementing embodiments using the cloud architecture, more or fewer resources can be used to, for example, Various embodiments described herein refer in some fashion to nodes, e.g., revenue management node 310. In some embodiments the non-limiting communication 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 a UE, a node in the operator network 300, the core network 302, the BSS 304 and the OCS 308. It can be radio network node or a node in the core network 302 or fixed part of the network such as the OCS 308.

[0061] Additionally, while embodiments described herein have described a telecommunication environment, the rerating process can be applied to other

environments and industries including, but not limited to, utilities or other services/products which use records and billing services. Embodiments also allow for only updating the subscribers and records that actually need to be updated this provides a number of efficiency improvements. More specifically, embodiments allow for reduced memory storage requirements to store multiple versions of the same rated records, as well as, more efficient post processing of the data as a reduced set of rerated events is

considered. Embodiments also allow for a reduced effort with respect to revenue assurance analysis as the number of updated records is reduced, when compared to conventional rerating methods. Also, if mistakes are made during rerating, less data is impacted and less data exists that could be rolled back during mistake correction and resource analysis provides the opportunity to make a partial update of counters and balances by only updating counters and balances that are impacted by the rerate.

[0062] The disclosed embodiments provide methods and devices for performing rerating and processes which support rerating. 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 spirit and scope of the invention. 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.

[0063] 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 rerating to include embodiments described herein, such as, the method associated with Figure 7, may take the form of a computer program product stored on a computer-readable storage medium having computer-readable instructions embodied in the medium. For example, Figure 9 depicts an electronic storage medium 900 on which computer program embodiments can be stored. 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. [0064] Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts provided in the present application may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a specifically programmed computer or processor.

Claims

WHAT IS CLAIMED IS:

1. A method for rerating subscriber usage event records associated with services, the method comprising:

identifying (702) a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger;

identifying (704) a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and

rerating (706) the subscriber usage events in the identified first and second subsets.

2. The method of claim 1 , wherein the step of identifying a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger further comprises:

rerating the subscriber usage event records to generate a new set of rated usage events; and

comparing the new set of rated events to the subscriber usage event records; wherein the second subset of the subscriber usage event records includes those subscriber usage event records from the new set of rated usage events which have different resource values as compared to a previously performed rating of the subscriber usage event records.

3. The method of claims 1 -2, further comprising:

updating only resources indicated by results of the step of rerating events.

4. The method of claims 2-3, wherein the resource is at least one of a cost or an account balance.

5. The method of claims 1 -4, wherein the usage event is associated with a product offering.

6. The method of claims 1 -5, wherein usage events that are directly impacted by the rerating trigger are triggered by one of backdated changes to a business configuration, backdated changes to customer data; backdated changes to network input data, one or more usage events that have been cancelled, and one or more events that have been reordered.

7. The method of claims 1 -6, wherein usage events that are indirectly impacted by the rerating trigger are identified by resource dependencies.

8. The method of claims 1 -7, wherein the step of rerating includes the step of assigning one of a new price, a discount and a change in accumulated balance to a usage event associated with the subscriber usage event records.

9. The method of claims 1 -8, wherein the step of rerating is performed by a network node.

10. The method of claim 9, wherein the network node is a revenue management node.

1 1. A system for rerating subscriber usage event records associated with services, the system comprising:

at least one network node (800) with at least one processor (802) configured to: identify (702) a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger;

identify (704) a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and

rerate (706) the subscriber usage events in the identified first and second subsets.

12. The system of claim 1 1 , wherein when the at least one network node with at least one processor performs the step of identifying a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger, the at least one network node with the at least one processor further performs the steps of:

comparing the new set of rated events to the subscriber usage event records; wherein the second subset of the subscriber usage event records includes those subscriber usage event records from the new set of rated usage events which have different resource values as compared to a previously performed rating of the

subscriber usage event records.

13. The system of claims 1 1 -12, wherein the at least one network node with the at least one processor further performs the step of:

updating only resources indicated by results of the step of rerating events.

14. The system of claims 12-13, wherein the resource is at least one of a cost or an account balance.

15. The system of claims 1 1 -14, wherein the usage event is associated with a product offering.

16. The system of claims 1 1 -15, wherein usage events that are directly impacted by the rerating trigger are triggered by one of backdated changes to a business configuration, backdated changes to customer data; backdated changes to network input data, one or more usage events that have been cancelled, and one or more events that have been reordered.

17. The system of claims 1 1 -16, wherein usage events that are indirectly impacted by the rerating trigger are identified by resource dependencies.

18. The system of claims 1 1 -17, wherein the step of rerating includes the step of assigning a new price, a discount and a change in accumulated balance to a usage event associated with the subscriber usage event records.

19. The system of claims 1 1 -18, wherein rerating is performed by a single network node.

20. The system of claim 19, wherein the network node is a revenue management node.

21 . A computer-readable storage medium (900) containing a computer-readable code that when read by a processor causes the processor to perform a method for rerating subscriber usage event records associated with telecommunication services

comprising:

22. An apparatus adapted to identify a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger; identify a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and rerate the subscriber usage events in the identified first and second subsets.

23. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of claims 1 -9.

24. A carrier containing the computer program of claim 23, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer-readable storage medium.

25. An apparatus comprising:

a first module configured to identify a first subset of the subscriber usage event records which have usage events that are directly impacted by a rerating trigger;

a second module configured to identify a second subset of the subscriber usage event records which have usage events that are indirectly impacted by the rerating trigger; and

a third module configured to rerate the subscriber usage events in the identified first and second subsets.