Abstract:
A distributed collaborative offline charging system and method is provided. Charging is determined by receiving a reduced charging record at a charging control function. The reduced charging record includes a charging data subset and an index for charging parameters that are not included in reduced charging record. The charging control function retrieves the charging parameters that are not included in reduced charging record utilizing the index.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates generally to communication systems. 
       BACKGROUND OF THE INVENTION 
       [0002]    The following is a list of acronyms used in the patent application. 
       3GPP 3rd Generation Partnership Project 
     ACR Automatic Charging Relay 
     AVP Attribute Value Pair 
     BD Billing Domain 
     CCF Charging Collection Function 
     CDF Charging Data Function 
     CDR Charging Data Record 
     CGF Charging Gateway Function 
     CPU Central Processing Unit 
     CTF Charging Trigger Function 
     EPC Evolved Packet Core 
     IMS IP Multimedia Subsystem 
     LTE Long Term Evolution 
     MMSC Multimedia Messaging Service Centre 
       [0003]    MMTel MultiMedia Telephony service 
       P-CSCF Proxy Call Session Control Function 
     PCC Policy and Charging Control 
     PCEF Policy Charging Enforcement Function 
     PCRF Policy and Charging Rules Function 
     PGW PDN Gateway 
       [0004]    Rf Radio frequency 
       SMSC Short Message Service Center 
     TTL Time To Live 
       [0005]    In network centralized charging architectures, network elements can create their own CDRs. Service providers often centralize this functionality in an offline charging system so that they can exercise tighter control on the format and contents of the CDRs produced centrally. Unfortunately, in a multi-vendor networks an operator incurs higher expenses if several vendors have to make modifications to CDRs, rather than having the changes done centrally at the CCF. 
         [0006]    In typical communication systems, the network elements do not create CDRs locally but rather send charging information to a CCF for both event and session based charging. The CCF typically creates a CDR per charging information received from network elements. In this architecture, network elements have to collect charging related parameters and send to the CCF in a real-time fashion, even if it is an offline charge. 
         [0007]    The CDRs in current communication systems include every bit of information that can be culled from the CTFs/Network Elements. This leads to a relatively large CDR. The CDR is handled by the downstream billing mediation system, which typically cuts away the non-essential information and thereby negates the processing applied by the upstream elements, namely network elements. This wastes bandwidth in transmission of such data. 
         [0008]    With increasing functions and features in communication networks, such as LTE/EPC networks, required mandatory and optional charging parameters have exponentially increased in last few years. Network elements collect a large number of charging parameters in real time and stuff them in ACR request messages to the CCF. Viewed as a single message, it may be a minimal amount of processing for today&#39;s high performance computing platforms. However, with the usage seen in LTE/EPC, for example, there may be millions of sessions going on simultaneously, and an operator invests in the equipment with the performance engineering requirements for the peak traffic to handle subscriber demand. It costs significant network elements CPU time and storage space for collecting and caching these parameters. It also increases the size of the Rf ACR message sent to the CCF which has to process the ACR with large data immediately. 
         [0009]    Therefore, current systems waste computing resources and network bandwidth. Additionally, the transmission of large amounts of data in real-time for an offline charging mechanism is inefficient and overly consumes system bandwidth. 
       BRIEF SUMMARY OF THE INVENTION 
       [0010]    An exemplary embodiment proposes a charging architecture in which PCEF/CTFs supply a few necessary AVPs in a reduced ACR towards the CCF. The CCF retrieves most of charging parameters from network databases offline before or even after it creates a CDR. An exemplary embodiment thereby provides a conservation of throughput through the communication system. 
         [0011]    Further, an exemplary embodiment optimizes the amount of data transferred between network elements. This significantly reduces the burden on the network elements to provide charging parameters in real time for offline charging. With this new feature, fewer new parameters are added into Rf ACR messages when functions and features are added in wireless networks. 
         [0012]    In accordance with an exemplary embodiment, wireless network elements are not required to collect and pass the majority of charging related parameters in real-time for offline charging. Further, PCEFs preferably only send reduced ACRs to the CCF, which significantly increases the throughput towards the CCF and reduces the bandwidth on the networks. Additionally, an index is added in the reduced ACR that allows the CCF to retrieve offline the needed charging data from network databases efficiently while using a minimum of network bandwidth. 
         [0013]    Still further, an exemplary embodiment provides for a policy engine to guide the charging data retrieving and CDR generation. In addition, the assembly of the CDR is preferably done in multiple stages across CDF, CGF and BD, with distributed processing logic that applies to fill in the final template desired in an operator deployment of billing functionality. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         [0014]      FIG. 1  depicts the functional architecture of a communication network in accordance with an exemplary embodiment of the present invention. 
           [0015]      FIG. 2  depicts a call flow diagram in accordance with an exemplary embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0016]      FIG. 1  depicts the functional architecture of a communication network  100  in accordance with an exemplary embodiment of the present invention. An exemplary embodiment of the present invention proposes a charging architecture in which charging functions supply only a few necessary AVPs in a reduced ACR towards CCF  103 , and CCF  103  retrieves most of the charging parameters from Network Databases  102  offline. This can occur before or after the CCF creates the CDR. By reducing the ACR, the burden on the network elements to provide charging parameters for offline charging is significantly reduced. This provides for fewer new parameters to be added to new Rf ACR messages, thereby minimizing system resource usage. 
         [0017]    Communication network  100  preferably includes PCEF  101 , Network Database  102 , and CCF  103 . It should be understood that additional network elements can be included in communication network  100 , but only these three are depicted for clarity. 
         [0018]    PCEF  101  is a network element that performs policy management, in particular policy-based traffic management and traffic shaping. PCEF  101  preferably enables the definition and application of business and operational rules, or policies, in Communication Network  100  and across telecommunication businesses. PCEF  101  can be a CTF or a PCEF. PCEF  101  provides the policy and charging enforcement function. In a 3GPP network, the PCRF and PCEF, along with the P-CSCF, make up the 3GPP PCC function. 
         [0019]    Network Database  102  is a database for storing, among other things, data for offline charging. Network DB  102  preferably stores call and session related data, which may or may not be related to charging. Network DB  102  can be a single database or a collection of databases, such as categorized databases, a centralized database, or individual service databases. 
         [0020]    Network DB  102  stores data that includes charging related information. The charging related data is preferably stored per call/session per subscriber, and can be retrieved per call/session per subscriber. In an exemplary embodiment, the charging related information is indexed. 
         [0021]    CCF  103  is a charging and billing system that creates and consolidates offline CDRs for IMS, LTE and various other network elements, to simplify billing system integration, maximize subscriber revenue, and reduce costs. CCF  103  can comprise a CDF, a CGF, a BD, or a combination of the three. 
         [0022]      FIG. 2  depicts a call flow diagram  200  in accordance with an exemplary embodiment of the present invention. In accordance with this exemplary embodiment, PCEF  101  does not include complete charging information in ACR messages. An exemplary embodiment provides an ACR for event- and session-based charging. 
         [0023]    In accordance with an exemplary embodiment, PCEF  101  sends Reduced ACR Message  201  to CCF  103 . Reduced ACR Message  201  preferably includes a subset of data and an index for parameters that are not included in Reduced ACR Message  201 . The data preferably includes only the AVPs that are required to provide charging for the call or session, which includes positional as well as non-positional AVPs. The index preferably includes not included call/session data, network data, or service data. The network data can be, for example, CTF data. The service data can be, for example, PS, SMSC, MMSC, or MMTel. The index can include single service charging information data or multiple service charging information data. 
         [0024]    CCF  103  sends Retrieve Missed Parameters Message  203  to Network DB  102  to retrieve missed parameters/field to generate complete CDRs. The index allows CCF  103  to know which charging parameters are omitted from Reduced ACR Message  201  so that CCF  103  can populate them by requesting them from Network DB  102 . 
         [0025]    When CCF  103  receives Reduced ACR Message  201 , CCF  103  creates a reduced CDR. In accordance with an exemplary embodiment, the reduced CDR does not include the missed parameters/fields in the reduced ACR. Creating the reduced CDR provides for a closure to charging transactions without involving a long wait. 
         [0026]    In accordance with a first exemplary embodiment, CCF  103  optimizes the retrieval of missed parameters by determining not to retrieve information that would be repetitious, such as information that CCF  103  already has. 
         [0027]    In accordance with a further exemplary embodiment, CCF  103  optimizes the retrieval of missed parameters by adding a new index to obtain additional charging data. 
         [0028]    In accordance with a further exemplary embodiment, CCF  103  optimizes the retrieval of missed parameters by defining a “time-to-live” (TTL) parameter. The TTL parameter relates to recently fetched information from a database and determines if a new query should be made for a parameter or should a previously cached version of the parameter can be utilized. 
         [0029]    In accordance with a further exemplary embodiment, CCF  103  optimizes the retrieval of missed parameters by configuring the policy engine, preferably via inputs from the billing domain, if certain parameters are of no interest to the billing domain. In such cases, queries for those parameters are preferably turned off. 
         [0030]    In accordance with a further exemplary embodiment, CCF  103  optimizes the retrieval of missed parameters by defining a fetch responsibility. The fetch responsibility can be assigned to a CDF, a CGF, or a BD. Alternately, the fetch responsibility can be set to all. In this embodiment, the fetch responsibility is assigned in a serial order. For example, the CDF would retrieve the missed parameters. If it failed in retrieving the parameters, the CGF would retrieve the missed parameters. If it failed in retrieving the parameters, the BD would retrieve the parameters. This ensures that CDRs are finalized as soon as possible on a high-transaction platform like the CCF. Further, the unavailability of one or more databases to be queried does not stall the processing pipeline at the CCF itself. 
         [0031]    In accordance with a further exemplary embodiment, CCF  103  optimizes the retrieval of missed parameters by indicating that the retrieval of the data can be done during a non-peak time to reduce network traffic. 
         [0032]    In accordance with a further exemplary embodiment, CCF  103  optimizes the retrieval of missed parameters by organizing the data retrieval to be in batch requests. CCF  103  can fill multiple CDRs for a single subscriber, multiple subscribers, single call/session or multiple sessions. CCF  103  or the BD preferably generate complete CDRs after filling required all fields. 
         [0033]    Network DB  102  retrieves missed parameters utilizing the index. Network DB  102  sends Missed Parameters Message  213  to CCF  103 . Missed Parameters Message  213  includes the missed parameters that were retrieved utilizing the index. 
         [0034]    CCF  103  receives Missed Parameters Message  213  from Network DB  102 . CCF  103  determines the missed parameters from Missed Parameters Message  213  utilizing the index from the reduced ACR. 
         [0035]    CCF  103  sends Report Message  211  to PCEF  101 . 
         [0036]    In accordance with an exemplary embodiment, the generation and storage of the reduced CDR provides a significant reduction in an overload condition and storage space, which are now big issues for service providers. 
         [0037]    While this invention has been described in terms of certain examples thereof, it is not intended that it be limited to the above description, but rather only to the extent set forth in the claims that follow.