US20150312743A1 - Override of distribution algorithms for an offline charging system - Google Patents
Override of distribution algorithms for an offline charging system Download PDFInfo
- Publication number
- US20150312743A1 US20150312743A1 US14/259,949 US201414259949A US2015312743A1 US 20150312743 A1 US20150312743 A1 US 20150312743A1 US 201414259949 A US201414259949 A US 201414259949A US 2015312743 A1 US2015312743 A1 US 2015312743A1
- Authority
- US
- United States
- Prior art keywords
- diameter
- cdf
- request
- distributor unit
- destination
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 claims abstract description 53
- 230000006870 function Effects 0.000 claims abstract description 23
- 230000008569 process Effects 0.000 description 20
- 102100026041 Acrosin Human genes 0.000 description 13
- 230000004044 response Effects 0.000 description 12
- ORQBXQOJMQIAOY-UHFFFAOYSA-N nobelium Chemical compound [No] ORQBXQOJMQIAOY-UHFFFAOYSA-N 0.000 description 9
- 101710205482 Nuclear factor 1 A-type Proteins 0.000 description 6
- 102100022165 Nuclear factor 1 B-type Human genes 0.000 description 6
- 101710170464 Nuclear factor 1 B-type Proteins 0.000 description 6
- 101710113455 Nuclear factor 1 C-type Proteins 0.000 description 6
- 101710140810 Nuclear factor 1 X-type Proteins 0.000 description 6
- 239000013311 covalent triazine framework Substances 0.000 description 6
- 238000010586 diagram Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 3
- 230000015654 memory Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 208000011597 CGF1 Diseases 0.000 description 1
- 230000001427 coherent effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000000875 corresponding effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 239000003550 marker Substances 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/24—Accounting or billing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/14—Charging, metering or billing arrangements for data wireline or wireless communications
- H04L12/1403—Architecture for metering, charging or billing
- H04L12/1407—Policy-and-charging control [PCC] architecture
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/65—Off-line charging system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/70—Administration or customization aspects; Counter-checking correct charges
Definitions
- the present disclosure is related to the field of communication systems and, in particular, to offline charging.
- Service providers typically provide numerous voice and data services to end users (also referred to as subscribers). Examples of voice services are voice calls, call forwarding, call waiting, etc. Examples of data services are streaming audio, streaming video, Voice over Internet Protocol (VoIP), online gaming, and IP-TV.
- the data services are managed by a packet core network, which interfaces the end user with external Packet Data Networks (PDN), such as the Internet.
- PDN Packet Data Networks
- Some examples of packet core networks are a General Packet Radio Service (GPRS) core network, an Evolved Packet Core (EPC) of a Long Term Evolution (LTE) network, etc.
- GPRS General Packet Radio Service
- EPC Evolved Packet Core
- LTE Long Term Evolution
- Mobile devices such as cell phones, personal data assistants, smart phones, notebook computers, etc., may access the data services provided by the networks over an air interface with one or more base stations.
- the service providers use offline and online charging functions to keep track of the resource usage incurred by each device for using the various services.
- the 3GPP/3GPP2 standards groups have defined a set of specifications that may be used to implement online charging systems and offline charging systems in the various network domains (e.g., a circuit-switched domain, a packet-switched domain, and/or a wireless domain), IP multimedia subsystems, and emerging 3G/OMA application services.
- offline charging is a process where charging information for network resource usage is collected concurrently with the resource usage.
- the charging information is passed through a chain of charging functions, which results in the generation of Charging Data Record (CDR) files that are transferred to the network operator's Billing Domain for subscriber billing and/or inter-operator accounting.
- CDR Charging Data Record
- a Charging Trigger Function is implemented in a network element that provides a service.
- the CTF collects information pertaining to chargeable events, assembles this information into matching charging events, and sends the charging events to a Charging Data Function (CDF), which may be implemented in the network element or in the Offline Charging System (OFCS).
- CDF Charging Data Function
- the CDF receives the charging events from one or more CTFs, and uses the information included in the charging events to construct CDRs.
- a CDR is a formatted collection of information about a chargeable event (e.g., time of call set-up, duration of the call, amount of data transferred, etc.) for use in billing and accounting.
- the CDF then sends the CDRs to a Charging Gateway Function (CGF) of the OFCS.
- CGF Charging Gateway Function
- the CGF acts as a gateway between the network and the billing domain. Therefore, the CGF collects CDRs from the CDF (and other CDFs), optionally correlates the CDRs and writes the CDRs into a CDR file, and makes the CDR file available to the billing domain.
- a typical operator network will utilize multiple CDFs and CGFs to implement offline charging.
- a front-end device such as a Diameter Routing Agent (DRA)
- DRA Diameter Routing Agent
- the front-end device typically uses a distribution algorithm to select a CDF for a particular session. For example, a distribution algorithm may process a session identifier from a Diameter ACR with a hashing function or another function to select a CDF. The front-end device then routes the Diameter ACR to the selected CDF.
- Embodiments described herein provide an enhancement to Diameter protocol by adding an override parameter.
- the override parameter indicates a CDF identity for a Diameter session, and a front-end distributor can use to the CDF identity for routing Diameter requests instead of using a distribution algorithm.
- the base Diameter protocol provides for identification of peers with attribute-value pairs (AVPs), such as Origin-Realm, Origin-Host, Destination-Realm, and Destination-Host.
- AVPs attribute-value pairs
- these AVPs in a Diameter request identify the distributor to the far end (CTF).
- CTF far end
- the distributor has to choose a destination CDF for the Diameter request, and route the Diameter request to the destination CDF.
- a front-end distributor would have to select a destination CDF using a distribution algorithm (or a table-driven approach) each time it received a Diameter request (e.g., Diameter ACR).
- a Diameter request e.g., Diameter ACR.
- the Diameter requests themselves can indicate a destination CDF for the requests so that the front-end distributor does not need to process the distribution algorithm for each Diameter request.
- One embodiment comprises a distributor unit configured to connect to a plurality of CDFs of an offline charging system.
- the distributor unit is configured to receive a Diameter request (e.g., a Diameter Accounting Request (ACR)) from a Charging Trigger Function (CTF) for a Diameter session, and to determine whether the Diameter request includes an override parameter indicating a destination CDF for the Diameter session.
- a Diameter request e.g., a Diameter Accounting Request (ACR)
- CTF Charging Trigger Function
- the distributor unit is configured to send the Diameter request to the destination CDF if the destination CDF is available.
- the distributor unit is configured to select the destination CDF based on a distribution algorithm, to insert the override parameter in the Diameter request indicating the destination CDF, and to send the Diameter request to the destination CDF.
- the distributor unit when the destination CDF indicated in the override parameter is not available, the distributor unit is configured to select an alternate destination CDF based on the distribution algorithm, to insert the override parameter in the Diameter request with a CDF identifier for the alternate destination CDF, and to send the Diameter request to the alternate destination CDF.
- the override parameter comprises a new Diameter Attribute Value Pair (AVP).
- the new Diameter AVP may have an attribute name of “CDF-Override” or something similar.
- the distributor unit is configured to receive a Diameter answer from the destination CDF that includes the override parameter, and to send the Diameter answer to the CTF.
- the CTF is configured to receive the Diameter answer from the distributor unit, and to store information for the destination CDF for the Diameter session.
- the CTF is further configured to generate another Diameter request for the Diameter session, to insert the override parameter in the other Diameter request indicating the destination CDF, and to send the other Diameter request to the distributor unit.
- Another embodiment comprises a method of distributing Diameter requests.
- the method comprises receiving a Diameter request in a distributor unit from a CTF for a Diameter session, where the distributor unit connects to a plurality of CDFs of an offline charging system.
- the method further includes determining whether the Diameter request includes an override parameter indicating a destination CDF for the Diameter session.
- the method includes sending the Diameter request to the destination CDF if the destination CDF is available.
- the method includes selecting the destination CDF based on a distribution algorithm, inserting the override parameter in the Diameter request indicating the destination CDF, and sending the Diameter request to the destination CDF.
- Another embodiment comprises a CTF of a network element.
- the CTF is configured to send a first Diameter request to a distributor unit for a Diameter session to implement offline charging, to receive a Diameter answer from the distributor unit that includes an override parameter indicating a destination Charging Data Function (CDF) selected by the distributor unit for the Diameter session, and to store information for the destination CDF for the Diameter session.
- the CTF is configured to generate a second Diameter request for the Diameter session, to insert the override parameter in the second Diameter request indicating the destination CDF, and to send the second Diameter request to the distributor unit.
- CDF Charging Data Function
- FIG. 1 illustrates an offline charging architecture in an exemplary embodiment.
- FIG. 2 is a flow chart illustrating a method for distributing Diameter requests in an exemplary embodiment.
- FIG. 3 is a flow chart illustrating a method for implementing an override process in an exemplary embodiment.
- FIG. 4 is a flow chart illustrating another method for implementing an override process in an exemplary embodiment.
- FIG. 5 is a message diagram illustrating the distribution of Diameter ACRs in an exemplary embodiment.
- FIG. 6 is another message diagram illustrating the distribution of Diameter ACRs in an exemplary embodiment.
- FIG. 1 illustrates an offline charging architecture 100 in an exemplary embodiment.
- Architecture 100 may be implemented in a circuit-switched network or a packet-switched network that provides services to its subscribers (i.e., end user and associated User Equipment (UE)) to provide offline charging for the subscribers.
- subscribers i.e., end user and associated User Equipment (UE)
- Some exemplary networks include IP Multimedia Subsystem (IMS) networks, Long Term Evolution (LTE) networks, General Packet Radio Service (GPRS), etc.
- IMS IP Multimedia Subsystem
- LTE Long Term Evolution
- GPRS General Packet Radio Service
- a network element 102 is an apparatus or equipment used in the provision of services provided by a network.
- a network element may comprise a Serving-Call Session Control Function (S-CSCF) or application server (AS) of an IMS network, a Serving Gateway (SGW) or a Packet Data Network Gateway (PGW) of an LTE network, etc.
- Network element 102 includes a Charging Trigger Function (CTF) 104 that detects chargeable events for services provided by network element 102 , assembles information for the chargeable events into matching charging events, and sends the charging events to a Charging Data Function (CDF).
- CTF Charging Trigger Function
- CTF 104 uses a Diameter Rf interface. Therefore, CTF 104 assembles the charging information into accounting requests, such as a Diameter Rf Accounting Request (ACR).
- ACR Diameter Rf Accounting Request
- FIG. 1 network element 102 may include a processor or other hardware component to implement CTF 104 .
- OFCS 120 is an apparatus, a server, a device, or equipment configured to implement offline charging for sessions or services provided by a network.
- Offline charging can be of two types: session-based or event-based.
- event-based charging the CTF reports the usage or the service rendered where the service offering is rendered in a single operation, such as subscriber registration, re-registration, de-registration, etc.
- the CTF reports the usage in an ACR EVENT.
- Session-based charging is the process of reporting usage reports for a session, and uses the START, INTERIM, and STOP accounting data.
- CTF may transmit multiple ACR Interims depending on the proceeding of the session.
- OFCS 120 includes a plurality of CDFs (CDF 1 -CDFn) 121 - 124 .
- a CDF comprises an element or module within OFCS 120 that receives charging events from CTFs within network elements, formats the charging events into CDRs, and sends the CDRs to a CGF.
- OFCS 120 also includes a plurality of CGFs (CGF 1 -CGFn) 141 - 144 .
- a CGF comprises an element or module within OFCS 120 that correlates CDRs for a session, and forwards a CDR file with the correlated CDRs to a billing domain 140 .
- Billing domain 140 is the part of the operator network that receives and processes CDR files for billing mediation and other billing applications (e.g., statistical applications).
- CDFs in OFCS 120 communicate with CGFs over a Diameter Ga interface.
- GTP′ is used on the Ga interface to transport CDRs from the CDFs to the CGFs. While a 1:1 relationship is shown between CDFs and CGFs in FIG. 1 , an N:1 relationship is also possible.
- OFCS 120 may include one or more processors or other hardware components that implement CDFs 121 - 124 and CGFs 131 - 134 .
- Distributor unit 110 is implemented between CTFs (e.g., CTF 104 ) and the CDFs 121 - 124 in OFCS 120 .
- the purpose of distributor unit 110 is to distribute Diameter requests or accounting requests (e.g., ACRs) from CTFs to the multiple CDFs 121 - 124 within OFCS 120 .
- distributor unit 110 includes an interface (I/F) 112 and a processor (PROC′R) 114 .
- Interface 112 comprises a component (e.g., hardware, software, or a combination of hardware and software) for communicating via Diameter Rf protocol or another type of protocol.
- Processor 114 comprises a component (i.e., hardware) that performs logic to distribute Diameter requests to the CDFs 121 - 124 .
- distributor unit 110 is illustrated as being outside of OFCS 120 , distributor unit 110 may be implemented on the same platform as OFCS 120 .
- the task of distributing Diameter requests may include considering the weights, current load index, and other parameters of CDFs 121 - 124 to select a CDF instance for handling ACRs for a session.
- Distributor unit 110 may follow a round-robin strategy in selecting a CDF for a particular session.
- Distributor unit 110 may work as a Back to Back User Agent (B2BUA), where Diameter sessions with a CTF are terminated on distributor unit 110 , and equivalent and corresponding Diameter sessions are started between distributor unit 110 and the selected CDF.
- B2BUA Back to Back User Agent
- Each CTF would have established a Diameter connection with distributor unit 110 , and send a Diameter ACR to distributor unit 110 that includes a Diameter “SessionId”.
- the Diameter “SessionId” is unique for the CTF for each session it reports.
- Distributor unit 110 is configured to select CDFs for ACRs based on a distribution algorithm.
- a distribution algorithm comprises any set of rules for calculating a CDF identity for a Diameter session (e.g., a Diameter ACR).
- distributor unit 110 may use a “consistent hashing” algorithm to select a CDF identity for a Diameter session.
- the consistent hashing algorithm may use the “SessionId” in the Diameter requests and CDF identifiers to select a CDF for a given Diameter request.
- the consistent hashing algorithm would generate N numbers for a given Diameter “SessionId”. The highest of the numbers may be chosen as the CDF for the Diameter session.
- distributor unit 110 may statically determine a hashed value for each CDF instance from its name:
- Hs 1 F(SvrNmCDF 1 )
- Hs 2 F(SvrNmCDF 2 )
- Hs 3 F(SvrNmCDF 3 )
- distributor unit 110 may dynamically determine a hashed value for each Diameter “SessionId” (DSID):
- This value is used in computing the hash for each set of (DSID, CDFName) for each of the CDFs:
- Distributor unit 110 may then select the CDF with highest Hc value for handling the Diameter session with the Diameter “SessionId” in question.
- Selecting a CDF identity based on a distribution algorithm as described above may also be acceptable the first time a Diameter request is received for a session.
- the distribution algorithm can be processor-intensive, and using the distribution algorithm each time a Diameter request is received can be a waste of resources.
- selecting a CDF identity for a Diameter session based on a distribution algorithm may be acceptable when the CDFs on an OFCS are operating correctly.
- it is often the case that one or more CDFs may be out of service for a time period. For example, if the CDFs are executed on a blade server, then one or more CDFs may be out of service if there are problems with one or more of the blades.
- a conventional distribution mechanism will use an algorithm to select a primary CDF for a Diameter session in response to receiving an initial ACR. If the primary CDF goes out of service, then the conventional distribution mechanism will select an alternate CDF for subsequent ACRs (e.g., interim). If the primary CDF happens to recover while the Diameter session is still active, then the conventional distribution mechanism will again use the algorithm to select the primary CDF for the Diameter session for subsequent ACRs. This scenario is a problem, as the primary CDF will receive some ACRs for the Diameter session, while the secondary CDF receives other ACRs for the session.
- a new override parameter is defined in Diameter protocol to override the use of a distribution algorithm (or other type of distribution methodology) by distributor unit 110 .
- a CDF is selected as the “destination CDF” for a Diameter session
- an identifier or other information for the destination CDF is inserted in the new override parameter of a Diameter message (request or answer).
- distributor unit 110 receives a Diameter request from a CTF, for example, distributor unit 110 is able to process the new override parameter of the Diameter request to identify the destination CDF for the Diameter session instead of using the distribution algorithm.
- CTF 104 detects a chargeable event for a service provided by network element 102 , and CTF 104 assembles information for the chargeable event into a Diameter request.
- the Diameter request may comprise a Diameter Rf ACR.
- CTF 104 may or may not insert an override parameter into the Diameter request at this point. For example, if the Diameter request is an ACR(start), then no destination CDF has been selected for this Diameter session. Thus, CTF 104 cannot insert a CDF identity for the destination CDF into an override parameter.
- Diameter request is an ACR(interim)
- a destination CDF has been selected for this Diameter session and CTF 104 may be able to insert a CDF identity for the destination CDF into an override parameter.
- CTF 104 then sends the Diameter request toward OFCS 120 .
- FIG. 2 is a flow chart illustrating a method 200 for distributing Diameter requests in an exemplary embodiment.
- the steps of method 200 will be described with reference to distributor unit 110 in FIG. 1 , but those skilled in the art will appreciate that method 200 may be performed in other systems. Also, the steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order.
- Interface 112 of distributor unit 110 receives the Diameter request from CTF 104 (step 202 ) for the Diameter session.
- Processor 114 determines whether the Diameter request includes an override parameter indicating a destination CDF for the session (step 204 ).
- the override parameter may contain any value that indicates the identity of a CDF 121 - 124 that was previously selected for this Diameter session as the destination CDF. For example, if the present Diameter request is an “interim” request, then CDF 121 may have been previously selected for the Diameter session in response to a “start” request.
- the override parameter may include/contain a CDF identifier (ID) for the destination CDF, routing information for the destination CDF, or other information.
- ID CDF identifier
- processor 114 selects a destination CDF (e.g., one of CDFs 121 - 124 ) for the Diameter request based on the distribution algorithm (step 206 ).
- a destination CDF e.g., one of CDFs 121 - 124
- processor 114 selects the destination CDF for the Diameter request according to its normal procedure using the distribution algorithm.
- processor 114 may use other methods of selecting a CDF other than a distribution algorithm, such as a lookup table.
- Diameter request is a “start” message
- the Diameter request will not have an override parameter, and the distribution algorithm will be used to select the CDF.
- Processor 114 then inserts the override parameter in the Diameter request indicating the destination CDF selected for the Diameter session (step 208 ).
- Processor 114 then sends the Diameter request to the destination CDF (step 210 ) through interface 112 .
- processor 114 determines if the destination CDF indicated in the override parameter is available (step 212 ). It may be the case that one or more CDFs 121 - 124 go out of service for a time period. Therefore, processor 114 determines whether the destination CDF indicated in the override parameter is available or in service. If the destination CDF is available, then processor 114 sends the Diameter request to the destination CDF (step 210 ). The Diameter request still includes the override parameter indicating the destination CDF.
- Processor 114 in essence overrides its normal logic of selecting a destination CDF for a Diameter request using the distribution algorithm when the Diameter request includes an override parameter indicating a destination CDF. Due to the override, processor 114 does not need to process the distribution algorithm to select a destination CDF for this Diameter request. If the Diameter request is either an “interim” or a “stop” message, then there should be an override parameter inserted in the Diameter request indicating the destination CDF already selected for the Diameter session.
- processor 114 selects an alternate destination CDF (e.g., one of CDFs 121 - 124 ) for the Diameter request based on the distribution algorithm (step 214 ). Processor 114 then inserts the override parameter in the Diameter request indicating the alternate destination CDF selected for the Diameter session (step 216 ), and sends the Diameter request to the alternate destination CDF (step 218 ) through interface 112 .
- an alternate destination CDF e.g., one of CDFs 121 - 124
- the override parameter may be inserted in all Diameter messages for this Diameter session so that each Diameter request is routed to the same CDF. For example, after a CDF is selected by distributor unit 110 for the session (e.g., based on the distribution algorithm), distributor unit 110 may insert the override parameter with the identity of the destination CDF in each Diameter message for the session. Therefore, Diameter requests sent from distributor unit 110 to the destination CDF include the override parameter. Likewise, Diameter answers (e.g., Diameter ACA) sent from the destination CDF to distributor unit 110 may also include the override parameter. Further, Diameter answers sent from distributor unit 110 to CTF 104 may also include the override parameter.
- Diameter answers e.g., Diameter ACA
- distributor unit 110 is able to notify the other elements (e.g., CTF 104 and the destination CDF) of the CDF identity selected for the Diameter session so that an override process can be performed. These elements can then include the override parameter in Diameter messages so that each Diameter request for the Diameter session is routed to the same CDF. This is further illustrated in FIGS. 3-4 .
- FIG. 3 is a flow chart illustrating a method 300 for implementing an override process in an exemplary embodiment. The steps of method 300 will be described with reference to CDF 121 in FIG. 1 , but those skilled in the art will appreciate that method 300 may be performed in other systems.
- the destination CDF receives the Diameter request from distributor unit 110 (step 302 ).
- CDF 121 determines whether the Diameter request includes an override parameter indicating the destination CDF for the Diameter session (step 304 ). If the Diameter request includes an override parameter, then CDF 121 compares a CDF ID in the override parameter with its own identifier (i.e., the actual identifier of CDF 121 ) (step 306 ). If the IDs match, then CDF 121 processes the Diameter request normally (step 308 ), which may include generating a Charging Data Record (CDR).
- CDR Charging Data Record
- CDF 121 also generates a Diameter answer (e.g., Accounting Answer (ACA)) as a response to the Diameter request (step 310 ), and inserts the override parameter in the Diameter answer indicating the destination CDF (step 312 ).
- CDF 121 may copy the override parameter from the Diameter request into the Diameter answer.
- CDF 121 then sends the Diameter answer to distributor unit 110 (step 314 ). If the IDs do not match, then CDF 121 may insert a corrected CDF ID in the override parameter of the Diameter answer (step 316 ).
- ACA Accounting Answer
- FIG. 4 is a flow chart illustrating a method 400 for implementing an override process in an exemplary embodiment. The steps of method 400 will be described with reference to CTF 104 in FIG. 1 , but those skilled in the art will appreciate that method 400 may be performed in other systems.
- CTF 104 receives the Diameter answer from distributor unit 110 (step 402 ). CTF 104 then determines that the Diameter answer includes the override parameter indicating a destination CDF for the Diameter session (step 404 ). CTF 104 then stores information for the destination CDF for the Diameter session (step 406 ), such as in a memory. CTF 104 may have a buffer for the Diameter sessions that are open, and the Diameter sessions are indexed or referenced in the buffer according to the “SessionId”. CTF 104 can therefore store information for the destination CDF along with other information for the Diameter session. For example, CTF 104 may store a CDF ID for the destination CDF for the Diameter session. CTF 104 stores the destination CDF information for the lifetime of the Diameter session, and deletes the destination CDF information when the session ends.
- CTF 104 then detects another chargeable event, and generates another Diameter request for the Diameter session (step 408 ). Based on the information it has stored for the Diameter session, CTF 104 is able to determine that a destination CDF has already been selected for this Diameter session. Therefore, CTF 104 inserts the override parameter in the Diameter request indicating the destination CDF for the Diameter session (step 410 ). For example, CTF 104 may insert a CDF ID for the destination CDF in the override parameter. CTF 104 then sends the Diameter request to distributor unit 110 (step 412 ).
- the override process then continues in distributor unit 110 (see FIG. 2 ).
- a new Attribute Value Pair may be defined in Diameter.
- the new AVP may have an attribute name of “CDF-Override”, although other attribute names may be used.
- This AVP is optional and its purpose is to create a marker for the messages that belong to a particular Diameter session.
- This AVP is of type “DiamIdent” (Diameter Identity) and is populated with the identity of the CDF instance selected for a Diameter session. The following illustrates the new AVP in a Diameter ACR:
- CDF-Override AVP would be expected to follow “-IS-”, meaning that it is not expected in the ACR Start and ACR Event, while it is expected in the ACR Interim and ACR Stop.
- ⁇ ACA> :: ⁇ Diameter Header: 271, PXY > ⁇ Session-Id > ⁇ Result-Code ⁇ ⁇ Origin-Host ⁇ ⁇ Origin-Realm ⁇ ⁇ Accounting-Record-Type ⁇ ⁇ Accounting-Record-Number ⁇ [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ User-Name ] [ Accounting-Sub-Session-Id ] [ Acct-Session-Id ] [ Acct-Multi-Session-Id ] [ Error-Message ] [ Error-Reporting-Host ] [ Failed-AVP ] [ Acct-Interim-Interval ] [ Accounting-Realtime-Required ] [ Origin-State-Id ] [ Event-Timestamp ] * [ Proxy-Info ] [CDF-Override] * [ AVP ]
- CDF-Override AVP would be expected to follow “SI- -”, meaning that it is not expected in the ACA Stop and ACA Event, while it is expected in the ACA Start and ACA Interim.
- FIG. 5 is a message diagram illustrating distribution of Diameter ACRs in an exemplary embodiment.
- CTF 104 detects a chargeable event for a service provided by network element 102 (see FIG. 1 ).
- CTF 104 assembles information for the chargeable event into a Diameter Rf ACR to initiate a Diameter session.
- the type of accounting for the service is session-based, so CTF 104 inserts a “start” value in the Accounting-Record-Type AVP of the ACR.
- CTF 104 then sends the ACR(start) to distributor unit 110 .
- distributor unit 110 determines whether the ACR(start) includes an override parameter. More particularly, distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(start). Because the Diameter session has just started, a destination CDF has not been selected for the Diameter session. Therefore, the ACR(start) does not include a “CDF-Override” AVP that indicates the destination CDF. Distributor unit 110 selects a destination CDF for the Diameter session based on the distribution algorithm (i.e., consistent hashing algorithm). In this instance, distributor unit 110 selects CDF 121 to handle the Diameter session.
- the distribution algorithm i.e., consistent hashing algorithm
- distributor unit 110 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(start).
- a value in the override parameter indicates the identity of CDF 121 . For example, if the identifier for CDF 121 is “SrvrNameCDF 1 ”, then distributor unit 110 inserts this value into the override parameter. Distributor unit 110 then routes the ACR(start) to CDF 121 .
- CDF 121 receives the ACR(start), and determines that the ACR(start) includes the override parameter. CDF 121 determines whether the CDF identity in the override parameter matches its own identity. If so, CDF 121 processes the ACR(start) normally, and generates a Diameter Rf Accounting Answer (ACA) as a response to the ACR(start). CDF 121 inserts the override parameter in the ACA(start) with the same CDF identity (of CDF 121 ) that was indicated in the ACR(start). CDF 121 then sends the ACA(start) to distributor unit 110 .
- ACA Diameter Rf Accounting Answer
- Distributor unit 110 receives the ACA(start), and routes the ACA(start) to CTF 104 with the override parameter.
- CTF 104 then stores the CDF identity for CDF 121 along with other information for the Diameter session.
- CTF 104 detects another chargeable event, and assembles information for the chargeable event into another Diameter ACR for the Diameter session.
- CTF 104 inserts a record type into the Diameter request indicating the ACR as an “interim” message.
- CTF 104 also determines that a destination CDF has already been selected for this Diameter session based on the override parameter provided in a prior ACA message (i.e., ACA(start)).
- CTF 104 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(interim).
- a value in the override parameter indicates the identity of CDF 121 .
- CTF 104 then sends the ACR(interim) to distributor unit 110 .
- distributor unit 110 determines whether the ACR(interim) includes an override parameter. More particularly, distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(interim). In this instance, the ACR(interim) does include an override parameter that indicates the identity of a destination CDF already selected for the Diameter session. Therefore, distributor unit 110 overrides the distribution algorithm, and routes the ACR(interim) to CDF 121 , which is the destination CDF indicated in the override parameter. Distributor unit 110 does not need to recalculate values for each CDF again based on the distribution algorithm in order to select the destination CDF for the Diameter session.
- CDF 121 receives the ACR(interim), and determines that the ACR(interim) includes the override parameter. CDF 121 also determines whether the CDF identity in the override parameter matches its own identity. If so, CDF 121 processes the ACR(interim) normally, and generates an ACA(interim) as a response to the ACR(interim). CDF 121 inserts the override parameter in the ACA(interim) with the same CDF identity (of CDF 121 ) that was indicated in the ACR(interim). CDF 121 then sends the ACA(interim) to distributor unit 110 . Distributor unit 110 receives the ACA(interim), and routes the ACA(interim) to CTF 104 with the override parameter.
- CTF 104 may detect multiple interim events, and send multiple ACRs(interim) to distributor unit 110 .
- Distributor unit 110 operates as described above for each ACR(interim) it receives.
- CTF 104 detects a final chargeable event, and assembles information for the chargeable event into a Diameter ACR(stop) for the Diameter session.
- CTF 104 inserts a record type into the ACR to indicate the ACR as a “stop” message.
- CTF 104 also determines that a destination CDF has already been selected for this Diameter session based on the override parameter provided in a prior ACA message (i.e., ACA(interim)). Therefore, CTF 104 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(stop).
- a value in the override parameter indicates the identity of CDF 121 .
- CTF 104 then sends the ACR(stop) to distributor unit 110 .
- distributor unit 110 determines whether the ACR(stop) includes an override parameter. More particularly, distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(stop). In this instance, the ACR(stop) does include an override parameter, so distributor unit 110 overrides the distribution algorithm, and routes the ACR(stop) to CDF 121 , which is the destination CDF indicated in the override parameter.
- distributor unit 110 can avoid calculating hashed values for each CDF in OFCS 120 when receiving ACR(interim)/(stop) messages.
- a CDF has already been selected for the Diameter session in response to an ACR(start). Therefore, the identity for the destination CDF is provided in the override parameter, and distributor unit 110 does not need to process the distribution algorithm in order to select a destination CDF for each Diameter ACR.
- FIG. 6 is another message diagram illustrating distribution of Diameter ACRs in an exemplary embodiment.
- the scenario illustrated in FIG. 6 is one a CDF is not available, and the distribution algorithm is overridden based on the override parameter.
- CTF 104 detects a chargeable event for a service provided by network element 102 (see FIG. 1 ), and assembles an ACR(start) for the Diameter session.
- CTF 104 then sends the ACR(start) to distributor unit 110 .
- distributor unit 110 determines whether the ACR(start) includes an override parameter. More particularly, distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(start).
- the ACR(start) does not include a “CDF-Override” AVP that indicates the destination CDF.
- Distributor unit 110 selects a destination CDF for the Diameter session based on the distribution algorithm (i.e., consistent hashing algorithm). In this instance, distributor unit 110 selects CDF 121 to handle the Diameter session. Because a destination CDF has been selected for this Diameter session, distributor unit 110 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(start). Distributor unit 110 then routes the ACR(start) to CDF 121 . CDF 121 then sends the ACA(start) to distributor unit 110 , which it routes to CTF 104 . CTF 104 then stores the CDF identity for CDF 121 along with other information for the Diameter session.
- the override parameter e.g., “CDF-Override” AVP
- CTF 104 detects another chargeable event, and assembles an ACR(interim).
- CTF 104 also determines that a destination CDF has already been selected for this Diameter session based on the override parameter provided in a prior ACA message (i.e., ACA(start)). Therefore, CTF 104 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(interim), with a value indicating the identity of CDF 121 .
- CTF 104 then sends the ACR(interim) to distributor unit 110 .
- distributor unit 110 determines whether the ACR(interim) includes an override parameter. More particularly, distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(interim). In this instance, the ACR(interim) does include an override parameter that indicates the identity of a destination CDF already selected for the Diameter session. Distributor unit 110 determines whether CDF 121 is available for the ACR(interim). In this case, CDF 121 has gone out of service ( 00 S) and is not available for the ACR(interim). Therefore, distributor unit 110 selects an alternate destination CDF for the Diameter session based on the distribution algorithm.
- distributor unit 110 selects CDF 122 to handle the Diameter session, as it is in service (IS) at this time.
- Distributor unit 110 updates the override parameter (e.g., “CDF-Override” AVP) in the ACR(interim) to indicate CDF 122 as the destination CDF.
- Distributor unit 110 then routes the ACR(interim) to CDF 122 .
- CDF 122 then sends the ACA(interim) to distributor unit 110 , which it routes to CTF 104 .
- CTF 104 then stores the CDF identity for CDF 122 along with other information for the Diameter session.
- CTF 104 If CTF 104 detects another interim chargeable event, it assembles another ACR(interim). CTF 104 also determines that a destination CDF has already been selected for this Diameter session based on the override parameter provided in a prior ACA message (i.e., ACA(interim)). Therefore, CTF 104 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(interim), with a value indicating the identity of CDF 122 . CTF 104 then sends the ACR(interim) to distributor unit 110 .
- override parameter e.g., “CDF-Override” AVP
- distributor unit 110 determines whether the ACR(interim) includes an override parameter. In this instance, the ACR(interim) does include an override parameter that indicates the identity of a destination CDF already selected for the Diameter session. Distributor unit 110 determines whether CDF 122 is available for the ACR(interim). In this case, CDF 122 is in service and is available for the ACR(interim). Therefore, distributor unit 110 routes the ACR(interim) to CDF 122 based on the information provided in the override parameter. FIG. 6 shows that CDF 121 had recovered at this time, and was in service. However, distributor unit 110 identifies the destination CDF based on the information in the override parameter.
- distributor unit 110 would have again selected CDF 121 as the destination CDF.
- One advantage to using the override process described above is that it prevents an out-of-service CDF from “hijacking” a Diameter session upon becoming in-service. If a distribution algorithm is used to select the destination CDF for a Diameter session but this destination CDF goes out-of-service, then the distribution algorithm will be used to select an alternate destination CDF. If the original destination CDF happens to recover while the Diameter session is still active, the distribution algorithm would again select the destination CDF for the Diameter session for subsequent ACRs. Using the override process described herein, CDF selection is forced by the CDF identity in the override parameter.
- the override parameter will force distributor unit 110 so use the alternate destination CDF.
- the alternate destination CDF will therefore be selected for the Diameter session instead of switching back to the original destination CDF once it recovers.
- any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these.
- an element may be implemented as dedicated hardware.
- Dedicated hardware elements may be referred to as “processors”, “controllers”, or some similar terminology.
- processors When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared.
- processor or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, a network processor, application specific integrated circuit (ASIC) or other circuitry, field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage, logic, or some other physical hardware component or module.
- DSP digital signal processor
- ASIC application specific integrated circuit
- FPGA field programmable gate array
- ROM read only memory
- RAM random access memory
- non-volatile storage logic, or some other physical hardware component or module.
- an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element.
- Some examples of instructions are software, program code, and firmware.
- the instructions are operational when executed by the processor to direct the processor to perform the functions of the element.
- the instructions may be stored on storage devices that are readable by the processor. Some examples of the storage devices are digital or solid-state memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
- The present disclosure is related to the field of communication systems and, in particular, to offline charging.
- Service providers typically provide numerous voice and data services to end users (also referred to as subscribers). Examples of voice services are voice calls, call forwarding, call waiting, etc. Examples of data services are streaming audio, streaming video, Voice over Internet Protocol (VoIP), online gaming, and IP-TV. The data services are managed by a packet core network, which interfaces the end user with external Packet Data Networks (PDN), such as the Internet. Some examples of packet core networks are a General Packet Radio Service (GPRS) core network, an Evolved Packet Core (EPC) of a Long Term Evolution (LTE) network, etc. Mobile devices, such as cell phones, personal data assistants, smart phones, notebook computers, etc., may access the data services provided by the networks over an air interface with one or more base stations.
- The service providers use offline and online charging functions to keep track of the resource usage incurred by each device for using the various services. The 3GPP/3GPP2 standards groups have defined a set of specifications that may be used to implement online charging systems and offline charging systems in the various network domains (e.g., a circuit-switched domain, a packet-switched domain, and/or a wireless domain), IP multimedia subsystems, and emerging 3G/OMA application services.
- According to 3GPP TS 32.240, offline charging is a process where charging information for network resource usage is collected concurrently with the resource usage. The charging information is passed through a chain of charging functions, which results in the generation of Charging Data Record (CDR) files that are transferred to the network operator's Billing Domain for subscriber billing and/or inter-operator accounting. To implement offline charging, a Charging Trigger Function (CTF) is implemented in a network element that provides a service. The CTF collects information pertaining to chargeable events, assembles this information into matching charging events, and sends the charging events to a Charging Data Function (CDF), which may be implemented in the network element or in the Offline Charging System (OFCS).
- The CDF receives the charging events from one or more CTFs, and uses the information included in the charging events to construct CDRs. A CDR is a formatted collection of information about a chargeable event (e.g., time of call set-up, duration of the call, amount of data transferred, etc.) for use in billing and accounting. The CDF then sends the CDRs to a Charging Gateway Function (CGF) of the OFCS. The CGF acts as a gateway between the network and the billing domain. Therefore, the CGF collects CDRs from the CDF (and other CDFs), optionally correlates the CDRs and writes the CDRs into a CDR file, and makes the CDR file available to the billing domain.
- A typical operator network will utilize multiple CDFs and CGFs to implement offline charging. Thus, a front-end device, such as a Diameter Routing Agent (DRA), is used in conjunction with the OFCS to distribute charging events from the CTFs to the CDFs. The front-end device typically uses a distribution algorithm to select a CDF for a particular session. For example, a distribution algorithm may process a session identifier from a Diameter ACR with a hashing function or another function to select a CDF. The front-end device then routes the Diameter ACR to the selected CDF.
- Embodiments described herein provide an enhancement to Diameter protocol by adding an override parameter. The override parameter indicates a CDF identity for a Diameter session, and a front-end distributor can use to the CDF identity for routing Diameter requests instead of using a distribution algorithm. The base Diameter protocol provides for identification of peers with attribute-value pairs (AVPs), such as Origin-Realm, Origin-Host, Destination-Realm, and Destination-Host. However, when used with a front-end distributor, these AVPs in a Diameter request identify the distributor to the far end (CTF). The distributor has to choose a destination CDF for the Diameter request, and route the Diameter request to the destination CDF. Previously, a front-end distributor would have to select a destination CDF using a distribution algorithm (or a table-driven approach) each time it received a Diameter request (e.g., Diameter ACR). By adding the override parameter to Diameter protocol, the Diameter requests themselves can indicate a destination CDF for the requests so that the front-end distributor does not need to process the distribution algorithm for each Diameter request.
- One embodiment comprises a distributor unit configured to connect to a plurality of CDFs of an offline charging system. The distributor unit is configured to receive a Diameter request (e.g., a Diameter Accounting Request (ACR)) from a Charging Trigger Function (CTF) for a Diameter session, and to determine whether the Diameter request includes an override parameter indicating a destination CDF for the Diameter session. When the Diameter request includes the override parameter, the distributor unit is configured to send the Diameter request to the destination CDF if the destination CDF is available. When the Diameter request does not include the override parameter, the distributor unit is configured to select the destination CDF based on a distribution algorithm, to insert the override parameter in the Diameter request indicating the destination CDF, and to send the Diameter request to the destination CDF.
- In one embodiment, when the destination CDF indicated in the override parameter is not available, the distributor unit is configured to select an alternate destination CDF based on the distribution algorithm, to insert the override parameter in the Diameter request with a CDF identifier for the alternate destination CDF, and to send the Diameter request to the alternate destination CDF.
- In one embodiment, the override parameter comprises a new Diameter Attribute Value Pair (AVP). The new Diameter AVP may have an attribute name of “CDF-Override” or something similar.
- In another embodiment, the distributor unit is configured to receive a Diameter answer from the destination CDF that includes the override parameter, and to send the Diameter answer to the CTF.
- In another embodiment, the CTF is configured to receive the Diameter answer from the distributor unit, and to store information for the destination CDF for the Diameter session. The CTF is further configured to generate another Diameter request for the Diameter session, to insert the override parameter in the other Diameter request indicating the destination CDF, and to send the other Diameter request to the distributor unit.
- Another embodiment comprises a method of distributing Diameter requests. The method comprises receiving a Diameter request in a distributor unit from a CTF for a Diameter session, where the distributor unit connects to a plurality of CDFs of an offline charging system. The method further includes determining whether the Diameter request includes an override parameter indicating a destination CDF for the Diameter session. When the Diameter request includes the override parameter, the method includes sending the Diameter request to the destination CDF if the destination CDF is available. When the Diameter request does not include the override parameter, the method includes selecting the destination CDF based on a distribution algorithm, inserting the override parameter in the Diameter request indicating the destination CDF, and sending the Diameter request to the destination CDF.
- Another embodiment comprises a CTF of a network element. The CTF is configured to send a first Diameter request to a distributor unit for a Diameter session to implement offline charging, to receive a Diameter answer from the distributor unit that includes an override parameter indicating a destination Charging Data Function (CDF) selected by the distributor unit for the Diameter session, and to store information for the destination CDF for the Diameter session. The CTF is configured to generate a second Diameter request for the Diameter session, to insert the override parameter in the second Diameter request indicating the destination CDF, and to send the second Diameter request to the distributor unit.
- The above summary provides a basic understanding of some aspects of the specification. This summary is not an extensive overview of the specification. It is intended to neither identify key or critical elements of the specification nor delineate any scope particular embodiments of the specification, or any scope of the claims. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is presented later.
- Some embodiments of the disclosure are now described, by way of example only, and with reference to the accompanying drawings. The same reference number represents the same element or the same type of element on all drawings.
-
FIG. 1 illustrates an offline charging architecture in an exemplary embodiment. -
FIG. 2 is a flow chart illustrating a method for distributing Diameter requests in an exemplary embodiment. -
FIG. 3 is a flow chart illustrating a method for implementing an override process in an exemplary embodiment. -
FIG. 4 is a flow chart illustrating another method for implementing an override process in an exemplary embodiment. -
FIG. 5 is a message diagram illustrating the distribution of Diameter ACRs in an exemplary embodiment. -
FIG. 6 is another message diagram illustrating the distribution of Diameter ACRs in an exemplary embodiment. - The figures and the following description illustrate specific exemplary embodiments. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. Furthermore, any examples described herein are intended to aid in understanding the principles of the embodiments, and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the inventive concept(s) is not limited to the specific embodiments or examples described below, but by the claims and their equivalents.
-
FIG. 1 illustrates anoffline charging architecture 100 in an exemplary embodiment.Architecture 100 may be implemented in a circuit-switched network or a packet-switched network that provides services to its subscribers (i.e., end user and associated User Equipment (UE)) to provide offline charging for the subscribers. Some exemplary networks include IP Multimedia Subsystem (IMS) networks, Long Term Evolution (LTE) networks, General Packet Radio Service (GPRS), etc. -
Architecture 100 includes anetwork element 102 that connects to an offline charging system (OFCS) 120 through adistributor unit 110. Anetwork element 102 is an apparatus or equipment used in the provision of services provided by a network. For example, a network element may comprise a Serving-Call Session Control Function (S-CSCF) or application server (AS) of an IMS network, a Serving Gateway (SGW) or a Packet Data Network Gateway (PGW) of an LTE network, etc.Network element 102 includes a Charging Trigger Function (CTF) 104 that detects chargeable events for services provided bynetwork element 102, assembles information for the chargeable events into matching charging events, and sends the charging events to a Charging Data Function (CDF). In the case ofnetwork element 102,CTF 104 uses a Diameter Rf interface. Therefore,CTF 104 assembles the charging information into accounting requests, such as a Diameter Rf Accounting Request (ACR). Although oneCTF 104 is illustrated inFIG. 1 , there may be many CTFs in contact withdistributor unit 110. Although not specifically illustrated inFIG. 1 ,network element 102 may include a processor or other hardware component to implementCTF 104. -
OFCS 120 is an apparatus, a server, a device, or equipment configured to implement offline charging for sessions or services provided by a network. Offline charging can be of two types: session-based or event-based. In event-based charging, the CTF reports the usage or the service rendered where the service offering is rendered in a single operation, such as subscriber registration, re-registration, de-registration, etc. The CTF reports the usage in an ACR EVENT. Session-based charging is the process of reporting usage reports for a session, and uses the START, INTERIM, and STOP accounting data. During a session, CTF may transmit multiple ACR Interims depending on the proceeding of the session. - In this embodiment,
OFCS 120 includes a plurality of CDFs (CDF1-CDFn) 121-124. A CDF comprises an element or module withinOFCS 120 that receives charging events from CTFs within network elements, formats the charging events into CDRs, and sends the CDRs to a CGF.OFCS 120 also includes a plurality of CGFs (CGF1-CGFn) 141-144. A CGF comprises an element or module withinOFCS 120 that correlates CDRs for a session, and forwards a CDR file with the correlated CDRs to abilling domain 140.Billing domain 140 is the part of the operator network that receives and processes CDR files for billing mediation and other billing applications (e.g., statistical applications). CDFs inOFCS 120 communicate with CGFs over a Diameter Ga interface. In the case shown inFIG. 1 , GTP′ is used on the Ga interface to transport CDRs from the CDFs to the CGFs. While a 1:1 relationship is shown between CDFs and CGFs inFIG. 1 , an N:1 relationship is also possible. Although not specifically illustrated inFIG. 1 ,OFCS 120 may include one or more processors or other hardware components that implement CDFs 121-124 and CGFs 131-134. -
Distributor unit 110 is implemented between CTFs (e.g., CTF 104) and the CDFs 121-124 inOFCS 120. The purpose ofdistributor unit 110 is to distribute Diameter requests or accounting requests (e.g., ACRs) from CTFs to the multiple CDFs 121-124 withinOFCS 120. In this embodiment,distributor unit 110 includes an interface (I/F) 112 and a processor (PROC′R) 114.Interface 112 comprises a component (e.g., hardware, software, or a combination of hardware and software) for communicating via Diameter Rf protocol or another type of protocol.Processor 114 comprises a component (i.e., hardware) that performs logic to distribute Diameter requests to the CDFs 121-124. Althoughdistributor unit 110 is illustrated as being outside ofOFCS 120,distributor unit 110 may be implemented on the same platform asOFCS 120. - The task of distributing Diameter requests may include considering the weights, current load index, and other parameters of CDFs 121-124 to select a CDF instance for handling ACRs for a session.
Distributor unit 110 may follow a round-robin strategy in selecting a CDF for a particular session.Distributor unit 110 may work as a Back to Back User Agent (B2BUA), where Diameter sessions with a CTF are terminated ondistributor unit 110, and equivalent and corresponding Diameter sessions are started betweendistributor unit 110 and the selected CDF. Each CTF would have established a Diameter connection withdistributor unit 110, and send a Diameter ACR todistributor unit 110 that includes a Diameter “SessionId”. The Diameter “SessionId” is unique for the CTF for each session it reports. -
Distributor unit 110 is configured to select CDFs for ACRs based on a distribution algorithm. A distribution algorithm comprises any set of rules for calculating a CDF identity for a Diameter session (e.g., a Diameter ACR). In one embodiment,distributor unit 110 may use a “consistent hashing” algorithm to select a CDF identity for a Diameter session. The consistent hashing algorithm may use the “SessionId” in the Diameter requests and CDF identifiers to select a CDF for a given Diameter request. With n CDFs present, such as inFIG. 1 , the consistent hashing algorithm would generate N numbers for a given Diameter “SessionId”. The highest of the numbers may be chosen as the CDF for the Diameter session. For example,distributor unit 110 may statically determine a hashed value for each CDF instance from its name: - Hs=F(CDFName)
- E.g., Hs1=F(SvrNmCDF1), Hs2=F(SvrNmCDF2), and Hs3=F(SvrNmCDF3)
- Then,
distributor unit 110 may dynamically determine a hashed value for each Diameter “SessionId” (DSID): - Hi=F(DiameterSessionID).
- This value is used in computing the hash for each set of (DSID, CDFName) for each of the CDFs:
- Hc=F(Hs, Hi)
-
Distributor unit 110 may then select the CDF with highest Hc value for handling the Diameter session with the Diameter “SessionId” in question. - Selecting a CDF identity based on a distribution algorithm as described above may also be acceptable the first time a Diameter request is received for a session. However, the distribution algorithm can be processor-intensive, and using the distribution algorithm each time a Diameter request is received can be a waste of resources. Also, selecting a CDF identity for a Diameter session based on a distribution algorithm may be acceptable when the CDFs on an OFCS are operating correctly. However, it is often the case that one or more CDFs may be out of service for a time period. For example, if the CDFs are executed on a blade server, then one or more CDFs may be out of service if there are problems with one or more of the blades. To illustrate the problem, a conventional distribution mechanism will use an algorithm to select a primary CDF for a Diameter session in response to receiving an initial ACR. If the primary CDF goes out of service, then the conventional distribution mechanism will select an alternate CDF for subsequent ACRs (e.g., interim). If the primary CDF happens to recover while the Diameter session is still active, then the conventional distribution mechanism will again use the algorithm to select the primary CDF for the Diameter session for subsequent ACRs. This scenario is a problem, as the primary CDF will receive some ACRs for the Diameter session, while the secondary CDF receives other ACRs for the session. This will cause ‘incomplete CDR’ generation on the primary CDF for the first part of the session, incomplete CDR generation on the secondary CDF for the second part of the session, and incomplete CDR generation again on the primary CDF for the last part of the session. This increases the complexity for the downstream billing mediation system to combine the multiple incomplete CDRs into a coherent and complete CDR for the session.
- In the following embodiments, a new override parameter is defined in Diameter protocol to override the use of a distribution algorithm (or other type of distribution methodology) by
distributor unit 110. As an overview, when a CDF is selected as the “destination CDF” for a Diameter session, an identifier or other information for the destination CDF is inserted in the new override parameter of a Diameter message (request or answer). Whendistributor unit 110 receives a Diameter request from a CTF, for example,distributor unit 110 is able to process the new override parameter of the Diameter request to identify the destination CDF for the Diameter session instead of using the distribution algorithm. - To illustrate the use of the override parameter in
FIG. 1 ,CTF 104 detects a chargeable event for a service provided bynetwork element 102, andCTF 104 assembles information for the chargeable event into a Diameter request. For example, the Diameter request may comprise a Diameter Rf ACR.CTF 104 may or may not insert an override parameter into the Diameter request at this point. For example, if the Diameter request is an ACR(start), then no destination CDF has been selected for this Diameter session. Thus,CTF 104 cannot insert a CDF identity for the destination CDF into an override parameter. If the Diameter request is an ACR(interim), then a destination CDF has been selected for this Diameter session andCTF 104 may be able to insert a CDF identity for the destination CDF into an override parameter. A further discussion of the operation of CTF is discussed below in relation toFIG. 4 .CTF 104 then sends the Diameter request towardOFCS 120. -
FIG. 2 is a flow chart illustrating amethod 200 for distributing Diameter requests in an exemplary embodiment. The steps ofmethod 200 will be described with reference todistributor unit 110 inFIG. 1 , but those skilled in the art will appreciate thatmethod 200 may be performed in other systems. Also, the steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order. - Interface 112 of
distributor unit 110 receives the Diameter request from CTF 104 (step 202) for the Diameter session.Processor 114 then determines whether the Diameter request includes an override parameter indicating a destination CDF for the session (step 204). The override parameter may contain any value that indicates the identity of a CDF 121-124 that was previously selected for this Diameter session as the destination CDF. For example, if the present Diameter request is an “interim” request, thenCDF 121 may have been previously selected for the Diameter session in response to a “start” request. The override parameter may include/contain a CDF identifier (ID) for the destination CDF, routing information for the destination CDF, or other information. - If/when the Diameter request does not include an override parameter, then
processor 114 selects a destination CDF (e.g., one of CDFs 121-124) for the Diameter request based on the distribution algorithm (step 206). In other words, when the Diameter request does not indicate a destination CDF that has already been selected for the Diameter session,processor 114 selects the destination CDF for the Diameter request according to its normal procedure using the distribution algorithm. Although a distribution algorithm is indicated as the normal procedure in this embodiment,processor 114 may use other methods of selecting a CDF other than a distribution algorithm, such as a lookup table. If the Diameter request is a “start” message, then the Diameter request will not have an override parameter, and the distribution algorithm will be used to select the CDF.Processor 114 then inserts the override parameter in the Diameter request indicating the destination CDF selected for the Diameter session (step 208).Processor 114 then sends the Diameter request to the destination CDF (step 210) throughinterface 112. - If/when the Diameter request includes an override parameter indicating a destination CDF, then
processor 114 determines if the destination CDF indicated in the override parameter is available (step 212). It may be the case that one or more CDFs 121-124 go out of service for a time period. Therefore,processor 114 determines whether the destination CDF indicated in the override parameter is available or in service. If the destination CDF is available, thenprocessor 114 sends the Diameter request to the destination CDF (step 210). The Diameter request still includes the override parameter indicating the destination CDF.Processor 114 in essence overrides its normal logic of selecting a destination CDF for a Diameter request using the distribution algorithm when the Diameter request includes an override parameter indicating a destination CDF. Due to the override,processor 114 does not need to process the distribution algorithm to select a destination CDF for this Diameter request. If the Diameter request is either an “interim” or a “stop” message, then there should be an override parameter inserted in the Diameter request indicating the destination CDF already selected for the Diameter session. - If the destination CDF indicated in the override parameter is not available, then
processor 114 selects an alternate destination CDF (e.g., one of CDFs 121-124) for the Diameter request based on the distribution algorithm (step 214).Processor 114 then inserts the override parameter in the Diameter request indicating the alternate destination CDF selected for the Diameter session (step 216), and sends the Diameter request to the alternate destination CDF (step 218) throughinterface 112. - The override parameter may be inserted in all Diameter messages for this Diameter session so that each Diameter request is routed to the same CDF. For example, after a CDF is selected by
distributor unit 110 for the session (e.g., based on the distribution algorithm),distributor unit 110 may insert the override parameter with the identity of the destination CDF in each Diameter message for the session. Therefore, Diameter requests sent fromdistributor unit 110 to the destination CDF include the override parameter. Likewise, Diameter answers (e.g., Diameter ACA) sent from the destination CDF todistributor unit 110 may also include the override parameter. Further, Diameter answers sent fromdistributor unit 110 toCTF 104 may also include the override parameter. Therefore,distributor unit 110 is able to notify the other elements (e.g.,CTF 104 and the destination CDF) of the CDF identity selected for the Diameter session so that an override process can be performed. These elements can then include the override parameter in Diameter messages so that each Diameter request for the Diameter session is routed to the same CDF. This is further illustrated inFIGS. 3-4 . -
FIG. 3 is a flow chart illustrating amethod 300 for implementing an override process in an exemplary embodiment. The steps ofmethod 300 will be described with reference toCDF 121 inFIG. 1 , but those skilled in the art will appreciate thatmethod 300 may be performed in other systems. - The destination CDF (CDF 121) receives the Diameter request from distributor unit 110 (step 302).
CDF 121 then determines whether the Diameter request includes an override parameter indicating the destination CDF for the Diameter session (step 304). If the Diameter request includes an override parameter, thenCDF 121 compares a CDF ID in the override parameter with its own identifier (i.e., the actual identifier of CDF 121) (step 306). If the IDs match, thenCDF 121 processes the Diameter request normally (step 308), which may include generating a Charging Data Record (CDR).CDF 121 also generates a Diameter answer (e.g., Accounting Answer (ACA)) as a response to the Diameter request (step 310), and inserts the override parameter in the Diameter answer indicating the destination CDF (step 312).CDF 121 may copy the override parameter from the Diameter request into the Diameter answer.CDF 121 then sends the Diameter answer to distributor unit 110 (step 314). If the IDs do not match, thenCDF 121 may insert a corrected CDF ID in the override parameter of the Diameter answer (step 316). - Referring to
FIG. 2 ,distributor unit 110 receives the Diameter answer from CDF 121 (step 220), and sends the Diameter answer toCTF 104 with the override parameter (step 222).FIG. 4 is a flow chart illustrating amethod 400 for implementing an override process in an exemplary embodiment. The steps ofmethod 400 will be described with reference toCTF 104 inFIG. 1 , but those skilled in the art will appreciate thatmethod 400 may be performed in other systems. -
CTF 104 receives the Diameter answer from distributor unit 110 (step 402).CTF 104 then determines that the Diameter answer includes the override parameter indicating a destination CDF for the Diameter session (step 404).CTF 104 then stores information for the destination CDF for the Diameter session (step 406), such as in a memory.CTF 104 may have a buffer for the Diameter sessions that are open, and the Diameter sessions are indexed or referenced in the buffer according to the “SessionId”.CTF 104 can therefore store information for the destination CDF along with other information for the Diameter session. For example,CTF 104 may store a CDF ID for the destination CDF for the Diameter session.CTF 104 stores the destination CDF information for the lifetime of the Diameter session, and deletes the destination CDF information when the session ends. -
CTF 104 then detects another chargeable event, and generates another Diameter request for the Diameter session (step 408). Based on the information it has stored for the Diameter session,CTF 104 is able to determine that a destination CDF has already been selected for this Diameter session. Therefore,CTF 104 inserts the override parameter in the Diameter request indicating the destination CDF for the Diameter session (step 410). For example,CTF 104 may insert a CDF ID for the destination CDF in the override parameter.CTF 104 then sends the Diameter request to distributor unit 110 (step 412). - The override process then continues in distributor unit 110 (see
FIG. 2 ). - In order to provide the override parameter in the requests/answers as described above, a new Attribute Value Pair (AVP) may be defined in Diameter. The new AVP may have an attribute name of “CDF-Override”, although other attribute names may be used. This AVP is optional and its purpose is to create a marker for the messages that belong to a particular Diameter session. This AVP is of type “DiamIdent” (Diameter Identity) and is populated with the identity of the CDF instance selected for a Diameter session. The following illustrates the new AVP in a Diameter ACR:
-
<ACR> ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Accounting-Record-Type } { Accounting-Record-Number } [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ User-Name ] [ Destination-Host ] [ Accounting-Sub-Session-Id ] [ Acct-Session-Id ] [ Acct-Multi-Session-Id ] [ Acct-Interim-Interval ] [ Accounting-Realtime-Required ] [ Origin-State-Id ] [ Event-Timestamp ] * [ Proxy-Info ] * [ Route-Record ] [CDF-Override] * [ AVP ] - Following the “SISE” convention, the CDF-Override AVP would be expected to follow “-IS-”, meaning that it is not expected in the ACR Start and ACR Event, while it is expected in the ACR Interim and ACR Stop.
- The following illustrates the new AVP in a Diameter ACA:
-
<ACA> ::=< Diameter Header: 271, PXY > < Session-Id > { Result-Code } { Origin-Host } { Origin-Realm } { Accounting-Record-Type } { Accounting-Record-Number } [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ User-Name ] [ Accounting-Sub-Session-Id ] [ Acct-Session-Id ] [ Acct-Multi-Session-Id ] [ Error-Message ] [ Error-Reporting-Host ] [ Failed-AVP ] [ Acct-Interim-Interval ] [ Accounting-Realtime-Required ] [ Origin-State-Id ] [ Event-Timestamp ] * [ Proxy-Info ] [CDF-Override] * [ AVP ] - Following the “SISE” convention, the CDF-Override AVP would be expected to follow “SI- -”, meaning that it is not expected in the ACA Stop and ACA Event, while it is expected in the ACA Start and ACA Interim.
-
FIG. 5 is a message diagram illustrating distribution of Diameter ACRs in an exemplary embodiment. To begin inFIG. 5 ,CTF 104 detects a chargeable event for a service provided by network element 102 (seeFIG. 1 ).CTF 104 assembles information for the chargeable event into a Diameter Rf ACR to initiate a Diameter session. The type of accounting for the service is session-based, soCTF 104 inserts a “start” value in the Accounting-Record-Type AVP of the ACR.CTF 104 then sends the ACR(start) todistributor unit 110. - In response to receiving the ACR(start),
distributor unit 110 determines whether the ACR(start) includes an override parameter. More particularly,distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(start). Because the Diameter session has just started, a destination CDF has not been selected for the Diameter session. Therefore, the ACR(start) does not include a “CDF-Override” AVP that indicates the destination CDF.Distributor unit 110 selects a destination CDF for the Diameter session based on the distribution algorithm (i.e., consistent hashing algorithm). In this instance,distributor unit 110 selectsCDF 121 to handle the Diameter session. Because a destination CDF has been selected for this Diameter session,distributor unit 110 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(start). A value in the override parameter indicates the identity ofCDF 121. For example, if the identifier forCDF 121 is “SrvrNameCDF1”, thendistributor unit 110 inserts this value into the override parameter.Distributor unit 110 then routes the ACR(start) toCDF 121. -
CDF 121 receives the ACR(start), and determines that the ACR(start) includes the override parameter.CDF 121 determines whether the CDF identity in the override parameter matches its own identity. If so,CDF 121 processes the ACR(start) normally, and generates a Diameter Rf Accounting Answer (ACA) as a response to the ACR(start).CDF 121 inserts the override parameter in the ACA(start) with the same CDF identity (of CDF 121) that was indicated in the ACR(start).CDF 121 then sends the ACA(start) todistributor unit 110. -
Distributor unit 110 receives the ACA(start), and routes the ACA(start) toCTF 104 with the override parameter.CTF 104 then stores the CDF identity forCDF 121 along with other information for the Diameter session. At a later time,CTF 104 detects another chargeable event, and assembles information for the chargeable event into another Diameter ACR for the Diameter session.CTF 104 inserts a record type into the Diameter request indicating the ACR as an “interim” message.CTF 104 also determines that a destination CDF has already been selected for this Diameter session based on the override parameter provided in a prior ACA message (i.e., ACA(start)). Therefore,CTF 104 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(interim). A value in the override parameter indicates the identity ofCDF 121.CTF 104 then sends the ACR(interim) todistributor unit 110. - In response to receiving the ACR(interim),
distributor unit 110 determines whether the ACR(interim) includes an override parameter. More particularly,distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(interim). In this instance, the ACR(interim) does include an override parameter that indicates the identity of a destination CDF already selected for the Diameter session. Therefore,distributor unit 110 overrides the distribution algorithm, and routes the ACR(interim) toCDF 121, which is the destination CDF indicated in the override parameter.Distributor unit 110 does not need to recalculate values for each CDF again based on the distribution algorithm in order to select the destination CDF for the Diameter session. -
CDF 121 receives the ACR(interim), and determines that the ACR(interim) includes the override parameter.CDF 121 also determines whether the CDF identity in the override parameter matches its own identity. If so,CDF 121 processes the ACR(interim) normally, and generates an ACA(interim) as a response to the ACR(interim).CDF 121 inserts the override parameter in the ACA(interim) with the same CDF identity (of CDF 121) that was indicated in the ACR(interim).CDF 121 then sends the ACA(interim) todistributor unit 110.Distributor unit 110 receives the ACA(interim), and routes the ACA(interim) toCTF 104 with the override parameter. -
CTF 104 may detect multiple interim events, and send multiple ACRs(interim) todistributor unit 110.Distributor unit 110 operates as described above for each ACR(interim) it receives. - At some point,
CTF 104 detects a final chargeable event, and assembles information for the chargeable event into a Diameter ACR(stop) for the Diameter session.CTF 104 inserts a record type into the ACR to indicate the ACR as a “stop” message.CTF 104 also determines that a destination CDF has already been selected for this Diameter session based on the override parameter provided in a prior ACA message (i.e., ACA(interim)). Therefore,CTF 104 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(stop). A value in the override parameter indicates the identity ofCDF 121.CTF 104 then sends the ACR(stop) todistributor unit 110. - In response to receiving the ACR(stop),
distributor unit 110 determines whether the ACR(stop) includes an override parameter. More particularly,distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(stop). In this instance, the ACR(stop) does include an override parameter, sodistributor unit 110 overrides the distribution algorithm, and routes the ACR(stop) toCDF 121, which is the destination CDF indicated in the override parameter. - One advantage to using the override process as described above is that
distributor unit 110 can avoid calculating hashed values for each CDF inOFCS 120 when receiving ACR(interim)/(stop) messages. A CDF has already been selected for the Diameter session in response to an ACR(start). Therefore, the identity for the destination CDF is provided in the override parameter, anddistributor unit 110 does not need to process the distribution algorithm in order to select a destination CDF for each Diameter ACR. -
FIG. 6 is another message diagram illustrating distribution of Diameter ACRs in an exemplary embodiment. The scenario illustrated inFIG. 6 is one a CDF is not available, and the distribution algorithm is overridden based on the override parameter. To begin inFIG. 6 ,CTF 104 detects a chargeable event for a service provided by network element 102 (seeFIG. 1 ), and assembles an ACR(start) for the Diameter session.CTF 104 then sends the ACR(start) todistributor unit 110. In response to receiving the ACR(start),distributor unit 110 determines whether the ACR(start) includes an override parameter. More particularly,distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(start). Because the Diameter session has just started, a destination CDF has not been selected for the Diameter session. Therefore, the ACR(start) does not include a “CDF-Override” AVP that indicates the destination CDF.Distributor unit 110 selects a destination CDF for the Diameter session based on the distribution algorithm (i.e., consistent hashing algorithm). In this instance,distributor unit 110 selectsCDF 121 to handle the Diameter session. Because a destination CDF has been selected for this Diameter session,distributor unit 110 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(start).Distributor unit 110 then routes the ACR(start) toCDF 121.CDF 121 then sends the ACA(start) todistributor unit 110, which it routes toCTF 104.CTF 104 then stores the CDF identity forCDF 121 along with other information for the Diameter session. - At a later time,
CTF 104 detects another chargeable event, and assembles an ACR(interim).CTF 104 also determines that a destination CDF has already been selected for this Diameter session based on the override parameter provided in a prior ACA message (i.e., ACA(start)). Therefore,CTF 104 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(interim), with a value indicating the identity ofCDF 121.CTF 104 then sends the ACR(interim) todistributor unit 110. - In response to receiving the ACR(interim),
distributor unit 110 determines whether the ACR(interim) includes an override parameter. More particularly,distributor unit 110 may determine whether a “CDF-Override” AVP is included in the ACR(interim). In this instance, the ACR(interim) does include an override parameter that indicates the identity of a destination CDF already selected for the Diameter session.Distributor unit 110 determines whetherCDF 121 is available for the ACR(interim). In this case,CDF 121 has gone out of service (00S) and is not available for the ACR(interim). Therefore,distributor unit 110 selects an alternate destination CDF for the Diameter session based on the distribution algorithm. In this instance,distributor unit 110 selectsCDF 122 to handle the Diameter session, as it is in service (IS) at this time.Distributor unit 110 updates the override parameter (e.g., “CDF-Override” AVP) in the ACR(interim) to indicateCDF 122 as the destination CDF.Distributor unit 110 then routes the ACR(interim) toCDF 122. -
CDF 122 then sends the ACA(interim) todistributor unit 110, which it routes toCTF 104.CTF 104 then stores the CDF identity forCDF 122 along with other information for the Diameter session. - If
CTF 104 detects another interim chargeable event, it assembles another ACR(interim).CTF 104 also determines that a destination CDF has already been selected for this Diameter session based on the override parameter provided in a prior ACA message (i.e., ACA(interim)). Therefore,CTF 104 inserts the override parameter (e.g., “CDF-Override” AVP) in the ACR(interim), with a value indicating the identity ofCDF 122.CTF 104 then sends the ACR(interim) todistributor unit 110. - In response to receiving the ACR(interim),
distributor unit 110 determines whether the ACR(interim) includes an override parameter. In this instance, the ACR(interim) does include an override parameter that indicates the identity of a destination CDF already selected for the Diameter session.Distributor unit 110 determines whetherCDF 122 is available for the ACR(interim). In this case,CDF 122 is in service and is available for the ACR(interim). Therefore,distributor unit 110 routes the ACR(interim) toCDF 122 based on the information provided in the override parameter.FIG. 6 shows thatCDF 121 had recovered at this time, and was in service. However,distributor unit 110 identifies the destination CDF based on the information in the override parameter. Ifdistributor unit 110 were to select the destination CDF based on the distribution algorithm, it would have again selectedCDF 121 as the destination CDF. One advantage to using the override process described above is that it prevents an out-of-service CDF from “hijacking” a Diameter session upon becoming in-service. If a distribution algorithm is used to select the destination CDF for a Diameter session but this destination CDF goes out-of-service, then the distribution algorithm will be used to select an alternate destination CDF. If the original destination CDF happens to recover while the Diameter session is still active, the distribution algorithm would again select the destination CDF for the Diameter session for subsequent ACRs. Using the override process described herein, CDF selection is forced by the CDF identity in the override parameter. Therefore, even if the original destination CDF recovers during the Diameter session, the override parameter will forcedistributor unit 110 so use the alternate destination CDF. The alternate destination CDF will therefore be selected for the Diameter session instead of switching back to the original destination CDF once it recovers. - Any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these. For example, an element may be implemented as dedicated hardware. Dedicated hardware elements may be referred to as “processors”, “controllers”, or some similar terminology. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, a network processor, application specific integrated circuit (ASIC) or other circuitry, field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage, logic, or some other physical hardware component or module.
- Also, an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element. Some examples of instructions are software, program code, and firmware. The instructions are operational when executed by the processor to direct the processor to perform the functions of the element. The instructions may be stored on storage devices that are readable by the processor. Some examples of the storage devices are digital or solid-state memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.
- Although specific embodiments were described herein, the scope of the disclosure is not limited to those specific embodiments. The scope of the disclosure is defined by the following claims and any equivalents thereof.
Claims (20)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/259,949 US9161199B1 (en) | 2014-04-23 | 2014-04-23 | Override of distribution algorithms for an offline charging system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/259,949 US9161199B1 (en) | 2014-04-23 | 2014-04-23 | Override of distribution algorithms for an offline charging system |
Publications (2)
Publication Number | Publication Date |
---|---|
US9161199B1 US9161199B1 (en) | 2015-10-13 |
US20150312743A1 true US20150312743A1 (en) | 2015-10-29 |
Family
ID=54252851
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/259,949 Expired - Fee Related US9161199B1 (en) | 2014-04-23 | 2014-04-23 | Override of distribution algorithms for an offline charging system |
Country Status (1)
Country | Link |
---|---|
US (1) | US9161199B1 (en) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170163818A1 (en) * | 2015-12-08 | 2017-06-08 | Alcatel-Lucent Usa Inc. | Telecommunication Offline Charging System |
US20170289784A1 (en) * | 2016-03-30 | 2017-10-05 | Alcatel-Lucent Usa Inc. | Dynamic Distribution In An Offline Charging System |
WO2018077091A1 (en) * | 2016-10-27 | 2018-05-03 | 中兴通讯股份有限公司 | Method, device and computer storage medium for charging data transmission |
CN109155737A (en) * | 2016-05-19 | 2019-01-04 | 诺基亚美国公司 | Destination for off-line accounting system selects to avoid reverse |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9538016B2 (en) * | 2014-10-31 | 2017-01-03 | Alcatel Lucent | Handling of reduced partial CDRs in an offline charging system |
US10644893B2 (en) | 2018-08-06 | 2020-05-05 | At&T Intellectual Property I, L.P. | Ensuring correctness of session identifiers in call duration records in mobile networks |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8862093B2 (en) * | 2012-06-29 | 2014-10-14 | Telefonaktiebolaget L M Ericsson (Publ) | Terminal-initiated override of charging system rules |
-
2014
- 2014-04-23 US US14/259,949 patent/US9161199B1/en not_active Expired - Fee Related
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170163818A1 (en) * | 2015-12-08 | 2017-06-08 | Alcatel-Lucent Usa Inc. | Telecommunication Offline Charging System |
US9942415B2 (en) * | 2015-12-08 | 2018-04-10 | Alcatel-Lucent Usa Inc. | Telecommunication offline charging system |
US20170289784A1 (en) * | 2016-03-30 | 2017-10-05 | Alcatel-Lucent Usa Inc. | Dynamic Distribution In An Offline Charging System |
US10104516B2 (en) * | 2016-03-30 | 2018-10-16 | Nokia Of America Corporation | Dynamic distribution in an offline charging system |
CN109417494A (en) * | 2016-03-30 | 2019-03-01 | 诺基亚美国公司 | Dynamic allocation in off-line accounting system |
CN109155737A (en) * | 2016-05-19 | 2019-01-04 | 诺基亚美国公司 | Destination for off-line accounting system selects to avoid reverse |
JP2019518281A (en) * | 2016-05-19 | 2019-06-27 | ノキア オブ アメリカ コーポレーション | Offline charging system destination selection to avoid backtracking |
WO2018077091A1 (en) * | 2016-10-27 | 2018-05-03 | 中兴通讯股份有限公司 | Method, device and computer storage medium for charging data transmission |
Also Published As
Publication number | Publication date |
---|---|
US9161199B1 (en) | 2015-10-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9438748B2 (en) | CDF tracking for offline charging | |
US9161199B1 (en) | Override of distribution algorithms for an offline charging system | |
US8737304B2 (en) | Methods, systems, and computer readable media for hybrid session based diameter routing | |
US8825060B2 (en) | Methods, systems, and computer readable media for dynamically learning diameter binding information | |
US9848090B2 (en) | Offline charging per service data flow | |
US9674373B2 (en) | Identification of timestamps for a partial CDR when failover occurs in an offline charging system | |
US20110161248A1 (en) | Online charging correlation in ims networks | |
KR20120123179A (en) | Distributive correlation of charging records across network domains | |
CN107078916B (en) | Processing to reduce partial CDR in offline charging system | |
US9560211B2 (en) | Error handling for CDR transport within an offline charging system | |
US9787852B2 (en) | Sequence number reuse for CDR transport using GTP' | |
US10117076B2 (en) | Destination selection for an offline charging system to avoid reversion | |
US9942415B2 (en) | Telecommunication offline charging system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ALCATEL-LUCENT USA INC., NEW JERSEY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SHARMA, RANJAN;REEL/FRAME:032836/0471 Effective date: 20140423 |
|
AS | Assignment |
Owner name: CREDIT SUISSE AG, NEW YORK Free format text: SECURITY INTEREST;ASSIGNOR:ALCATEL LUCENT USA, INC.;REEL/FRAME:033500/0156 Effective date: 20140806 |
|
AS | Assignment |
Owner name: ALCATEL-LUCENT USA, INC., NEW JERSEY Free format text: RELEASE OF SECURITY INTEREST;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:033596/0898 Effective date: 20140819 |
|
AS | Assignment |
Owner name: ALCATEL-LUCENT USA INC., NEW YORK Free format text: RELEASE OF SECURITY INTEREST;ASSIGNOR:CREDIT SUISSE AG;REEL/FRAME:033684/0046 Effective date: 20140819 |
|
FEPP | Fee payment procedure |
Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Year of fee payment: 4 |
|
FEPP | Fee payment procedure |
Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
LAPS | Lapse for failure to pay maintenance fees |
Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCH | Information on status: patent discontinuation |
Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362 |
|
FP | Lapsed due to failure to pay maintenance fee |
Effective date: 20231013 |