Implementations described herein relate generally to credit-control systems and, more particularly, to the implementation of dynamic centralized unit determination in a credit control charging system based on service unit requests.
Credit control may involve mechanisms that interact in real-time with accounts associated with end users, and may control or monitor the charges related to service usage associated with those end users' accounts. For example, credit control may involve checking whether credit is available for a given account, reserving credit, deducting credit from the end user account when service is completed, and/or refunding reserved credit that is not used. Credit control has particular applicability in the provision of network services, such as, for example, provision of cellular airtime in a cellular radio network, provision of multimedia data in a wired or wireless network, etc. Credit control may be implemented by a charging system (e.g., a credit control server) that monitors and controls charges related to service usage of end users, and that grants and/or denies credit authorizations to those end users, thus, enabling network service delivery to the end users.
RFC 4006, entitled “Diameter Credit-Control Application” (DCCA), provides a specification that can be used to implement real-time credit-control for a variety of end user services such as network access services, Session Initiation Protocol (SIP) services, messaging services, and download services. RFC 4006 provides a general solution to real-time cost and credit-control in charging systems.
A credit control charging session typically involves the receipt of a request for service units at a charging system (e.g., the credit control server) that checks credit availability, reserves service units, and/or grants service units to an end user that is using a network service. Upon receipt of the request for service units, the charging system may perform various functions to enable the charging system to grant service units to the end user. Mechanisms for granting service units during a credit control charging session typically lack the capacity to determine charging session related parameters in ways that satisfy market requirements. For example, mechanisms for granting service units during a credit control charging session lack the capacity to determine charging session related parameters (e.g., unit type, validity time, etc.) based on, for example, certain input parameters (e.g., roaming position, etc.) obtained from the request for service units or based on certain account data (e.g., a particular offered campaign) associated with the end user.
Exemplary embodiments described herein relate to centralized unit determination that may be performed at a charging system, during the service unit granting process, in response to a request for service units received in association with an end user's charging session. As described herein, a dynamic centralized unit determination module may be implemented in the charging system using dynamically configurable logic to implement the centralized unit determination. The centralized unit determination may include determining one or more charging session related parameters based on input parameters contained in the request for service units and based on account data of an account associated with the end user. The charging session related parameters may include a service unit type (e.g., service unit type of time, data volume, or money) to be granted to the charging session, or other charging session related data. The other charging session related data may include parameters, other than service unit type, related to a particular charging session (e.g., a validity-time parameter which can be used for a service unit reservation that depends on account parameters). The determined charging session related parameters may be used by a rating engine of the charging system to grant an amount of service units to the end user and/or may be returned to a client and/or service element that is engaged in providing a network service to the end user. Use of the dynamic centralized unit determination module, described herein, advantageously enables the determination of unit type, and/or other charging session related parameters, based on various different input parameters obtained from request for service units, or from end user account data. By implementing the dynamic centralized unit determination module with dynamically configurable logic, the determination of unit type, and/or charging session related parameters, may be performed in a flexible way that may be easily re-configured based upon end user or service provider needs or requirements.
According to one aspect, a charging system may include a rating engine, and a session control module to: receive a request for service units, associated with a charging session, from a client or service element that is providing a network service to an end user, and obtain one or more input parameters from the request for service units. The charging system may further include a charging unit determination module to: obtain account data associated with the request for service units from an account balance management module, determine at least one charging session related parameter based on the one or more input parameters and/or the account data, and pass the at least one charging session related parameter to the rating engine. The rating engine is to: grant service units based on the at least one charging session related parameter, and forward an indication of the granted service units to the session control module for return to the client or service element.
According to a further aspect, a method implemented in a charging system may include receiving a request for service units, associated with a charging session, from a client or service element that is providing a network service to an end user, and obtaining one or more input parameters from the request for service units. The method may further include obtaining account data associated with the request for service units, and determining at least one charging session related parameter based on the one or more input parameters and/or the account data. The method may also include granting service units based on the at least one charging session related parameter, and sending an indication of the granted service units to the client or service element.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments of the invention and, together with the description, explain the invention. In the drawings:
The following detailed description of the invention refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. Also, the following detailed description does not limit the invention.
Charging system 130 may include a server entity that performs credit-control associated with one or more network services. Charging system 130 may perform the credit-control before a service event is delivered to one or more of end users 105-1 through 105-N. In implementations described herein, charging system 130 may implement dynamic centralized unit determination based on, for example, input parameters contained in service unit requests (e.g., Request for Service Units (RSU)) and based on account data associated with end users 105-1 through 105-N.
As shown in
Each of end users 105-1 through 105-N may include a cellular radiotelephone, a personal digital assistant (PDA), a Personal Communications Systems (PCS) terminal, a laptop computer, a desktop computer, a palmtop computer, or any other type of device or appliance that includes a communication transceiver that permits the device to communicate with other devices. A PCS terminal may combine a cellular radiotelephone with data processing, facsimile, and data communications capabilities. A PDA may include a radiotelephone, a pager, an Internet/intranet access device, a web browser, an organizer, calendars, and/or a global positioning system (GPS) receiver. A PCS or PDA may include a Session Initiation Protocol (SIP) User Agent (SIP UA) which may be used for SIP signaling in a Internet Protocol (IP) Multimedia Subsystem (IMS) domain.
Network 110 may include one or more networks of any type, including a local area network (LAN); a wide area network (WAN); a metropolitan area network (MAN); a telephone network, such as a Public Switched Telephone Network (PSTN) or a Public Land Mobile Network (PLMN); a satellite network; an intranet, the Internet; or a combination of these and/or other types of networks. The PLMN(s) may further include a packet-switched sub-network, such as, for example, General Packet Radio Service (GPRS), Cellular Digital Packet Data (CDPD), a Mobile Internet Protocol (IP) network, or an IMS network.
It will be appreciated that the components illustrated in
Processing unit 220 may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Main memory 230 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor 220. ROM 240 may include a ROM device or another type of static storage device that may store static information and instructions for use by processing unit 220. Storage device 250 may include a magnetic and/or optical recording medium and its corresponding drive.
Input device 260 may include a mechanism that permits an operator to input information to device 200, such as a keyboard, a mouse, a pen, voice recognition, a touch screen display, and/or biometric mechanisms, etc. Output device 270 may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface 280 may include any transceiver-like mechanism that enables device 200 to communicate with other devices and/or systems. For example, communication interface 280 may include mechanisms for communicating with another device or system via a network, such as network 110.
Device 200 may perform certain operations/processes described herein. Device 200 may perform these operations in response to processing unit 220 executing software instructions contained in a computer-readable medium, such as memory 230, ROM 240, and/or storage device 250. A computer-readable medium may be defined as a physical or logical memory device. Each of main memory 230, ROM 240 and storage device 250 may include computer-readable media. The magnetic and/or optical recording media (e.g., readable CDs or DVDs) of storage device 250 may also include computer-readable media.
The software instructions may be read into memory 230 from another computer-readable medium, such as storage device 250, or from another device via communication interface 280. The software instructions contained in memory 230 may cause processing unit 220 to perform operations or processes described herein. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
It will be appreciated that the components illustrated in
Session control module 300 may receive charging requests associated with charging sessions from clients 115-1 through 115-M. Session control module 300 may process the charging requests to obtain one or more input parameters from the charging requests. The one or more input parameters may include, but are not limited to, an SGSN address of the SGSN serving an end user, the GGSN address of the GGSN serving the end user, the Mobile Country Code (MCC) associated with the location of the end user, the Mobile Network Code (MNC) associated with the location of the end user, and/or a service class of the end user's traffic. Session control module 300 may pass the input parameters to dynamic centralized unit determination (DCUD) module 310 and to rating engine 330.
DCUD module 310 may receive the input parameter(s) from session control module 300 and may obtain account data, associated with the charging requests, from account balance management module 320. DCUD module 310 may include dynamically configurable logic for performing, among other functions, unit type determination (i.e., a type of service unit to be granted, such as, time, volume, or money) based on the input parameters and the account data as configured through interface 350 using Management Application 340. DCUD module 310 may also include dynamically configurable logic for determining other charging session related parameters based on the input parameters, the account data and/or other data. The other charging session related parameter(s) may include, for example, one or more of the following parameters that are defined in “Diameter Charging Applications,” 3GPP TS 32.299 V7.7.0 2007-09: 1) a trigger parameter(s); 2) a threshold parameter(s); 3) a Continuous Time Period (CTP) or Discrete Time Period (DTP) parameter(s); 4) an envelope reporting parameter(s); 5) a Quota Holding Time (QHT) parameter(s); and 6) a Quota Consumption Time (QCT) parameter(s). For example, the QCT parameter(s) may be determined based on account data associated with the end user (e.g., based on whether the end user is participating in a particular offer or is a member of a particular group). The QCT parameter(s) may inform the client or service element to “over consume” (i.e., consume units even though no traffic flows) during a time period specified by the QCT parameter(s). As another example, the CTP or DTP parameters may be determined based on account data associated with the end user (e.g., based on whether the end user is participating in a particular offer or is a member of a particular group). The CTP or DTP parameters may inform the client or service element of time envelopes which define rules of consumption to be applied to downloaded units.
DCUD module 310 may pass the determined service unit type to rating engine 330. DCUD module 310 may also pass the determined other charging session related parameters to rating engine 330, and to session control module 300 for return to the client or service element. The configurable logic used by DCUD module 310 may include any type of logic, such as, for example, Javascript, Python, or Perl programmable logic. In one implementation, the configurable logic used by DCUD module 310 may include a logical tree structure that further includes various “branches.” Each of the branches may include conditions and modifiers, as described in further detail below with respect to
Account balance management module 320 may maintain account data (e.g., account balance information) for accounts associated with each of end users 105-1 through 105-N. Account balance management module 320 may supply the account data to DCUD module 310 or rating engine 330 based on credit requests associated with respective ones of end users 105-1 through 105-N. The account data may include, but is not limited to, a current monetary value of a main account associated with an end user, a current value of promotional accounts associated with the end user, a current value of usage accumulators (UAs) associated with the end user, promotions and campaigns offered to the end user, family and friend numbers associated with the end user, and communities to which the end user belongs. Each account associated with an end user may store the above-noted account information, and possibly other information.
Rating engine 330 may use the input parameters, the account data, the determined service unit type, the other charging session related data, and/or other data to reserve service units related to a respective charging request, and/or to update account data of the account related to a respective charging request. Rating engine 330 may pass an indication of the reserved service units to session control module 300 for return to the client or service element.
Management application 340 may include functionality for entering new logic into DCUD module 310, or for modifying existing logic of DCUD module 310. A user (e.g., an administrator of charging system 130) may use user I/F 350 to control the functionality of management application 340 to enter new logic into DCUD module 310 or to modify existing logic of DCUD module 310.
The functional components illustrated in
The exemplary process may include providing a user interface for entry of new logic (block 600). Management application 340 may implement a user interface that a user (e.g., an administrator) may be use to enter new logic. For example, management application 340 may implement user I/F 350 depicted in
Returning to
The blocks of
The exemplary process may include receiving new and/or modified logic at DCUD module 130 (block 800). In accordance with blocks 615 or 630 of the exemplary process of
DCUD module 310 may determine a service unit type based on the input parameter(s), the user account data, and/or other data (block 815). DCUD module 310 may implement the logic received in block 800 to determine the service unit type to be granted. For example, if the logic includes a logical tree structure, DCUD module 310 may apply one or more conditions and modifiers (described above) to determine the service unit type to be granted. DCUD module 310 may determine the service unit type based on, for example, an SGSN address associated with the location of the end user, a GGSN address associated with the location of the end user, a MCC associated with a location of the end user, a MNC associated with a location of the end user, a campaign identifier associated with an advertising campaign in which the end user is participating; a time of day associated with a time a request for service units is received by charging system 130, or a traffic service class associated with the request for service units.
DCUD module 310 may send the determined service unit type to session control module 300, for passing to rating engine 340, for credit rating and service unit reservation (block 820). As shown in
DCUD module 310 may determine other charging session related parameter(s) based on the input parameter(s), user account data, and/or other data (block 825). DCUD module 310 may implement the logic received in block 800 to determine the other charging session related parameter(s). For example, if the logic includes a logical tree structure, DCUD module 310 may apply one or more conditions and modifiers (described above) to determine the other charging session related parameter(s) based on the input parameter(s), user account data, and/or other data. The other charging session related parameter(s) may include one or more of the following parameters that are defined in “Diameter Charging Applications,” 3GPP TS 32.299 V7.7.0 2007-09: 1) a trigger parameter(s); 2) a threshold parameter(s); 3) a Continuous Time Period (CTP) or Discrete Time Period (DTP) parameter(s); 4) an envelope reporting parameter(s); 5) a Quota Holding Time (QHT) parameter(s); and 6) a Quota Consumption Time (QCT) parameter(s). For example, the QCT parameter(s) may be determined based on account data associated with the end user (e.g., based on whether the end user is participating in a particular offer or is a member of a particular group). The QCT parameter(s) may inform the client or service element to “over consume” (i.e., consume service units even though no traffic flows) during a time period specified by the QCT parameter(s). As another example, the CTP or DTP parameters may be determined based on account data associated with the end user (e.g., based on whether the end user is participating in a particular offer or is a member of a particular group). The CTP or DTP parameters may inform the client or service element of time envelopes which define rules of consumption to be applied to downloaded service units.
DCUD module 310 may send the other charging session related parameter(s) to session control module 300 for returning to the client or service element (block 830). As shown in
The blocks depicted in
In the example of
The foregoing description of implementations provides illustration and description, but is not intended to be exhaustive or to limit the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings, or may be acquired from practice of the invention. For example, while series of blocks have been described with regard to
Aspects described herein may also be implemented in methods and/or computer program products. Accordingly, the embodiments described herein may be embodied in hardware and/or in a combination of hardware and software (including firmware, resident software, microcode, etc.). Furthermore, embodiments described herein may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. The actual software code or specialized control hardware used to implement the embodiments described herein is not limiting of the invention. Thus, the operation and behavior of the embodiments were described without reference to the specific software code—it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement the aspects based on the description herein.
Furthermore, certain portions of the invention may be implemented as “logic” that performs one or more functions. This logic may include hardware, such as an application specific integrated circuit or field programmable gate array, or a combination of hardware and software.
Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the invention. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.
It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps, components or groups but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.
No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such. Also, as used herein, the article “a” is intended to include one or more items. Where only one item is intended, the term “one” or similar language is used. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.
Number | Name | Date | Kind |
---|---|---|---|
8141165 | Ginter et al. | Mar 2012 | B2 |
20070179974 | Cai et al. | Aug 2007 | A1 |
20080040267 | Krishnamoorthy et al. | Feb 2008 | A1 |
20080205614 | Cai et al. | Aug 2008 | A1 |
20090299820 | Wang et al. | Dec 2009 | A1 |
Number | Date | Country |
---|---|---|
WO 2004036825 | Apr 2004 | WO |
Entry |
---|
3GPP TS 32.296 V8.2.0 (Jun. 2008). |
3GPP TS 32.299 V7.7.0, “3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Charging management; Diameter charging applications (Release 7)”, Sep. 2007, pp. 1-120. |
H. Hakala et al., “Diameter Credit-Control Application”, Network Working Group, Aug. 2005, pp. 1-114. |
ETSI TS 132 240 V7.2.0, “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Telecommunications management; Charging management; Charging architecture and principles (3GPP TS 32.240 version 7.2.0 Release 7)”, Mar. 2007, pp. 1-45. |
ETSI TS 132 251 V7.5.1, “Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Telecommunications management; Charging management; Packet Switched (PS) domain charging (3GPP TS 32.251 version 7.5.1 Release 7)”, Oct. 2007, pp. 1-67. |
“3GPP TS 32.296 V8.2.0 (20008-06); 3rd Generation Partnership Project; Technical Specification Group Service and System Aspects; Telecommunication management; Online Charging System (OCS): Application and interfaces (Release 8)”, 3GPP TS 32.296 V8.2.0, vol. 32.296, No. V8.2.0, Jun. 17, 2008, pp. 1-77, XP002525705, p. 11, line 1—p. 50, last line. |
“Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Policy and charging control architecture (3GPP TS 23.203 version 8.6.0 Release 8)”, Technical Specification, European Telecommunications Standards Institute (ETSI), 650, Route Des Lucioles; F-06921 Sophia-Antipolis; France, No. V8.6.0, Jun. 1, 2009, XP014044524, p. 16, Line 4—p. 56, last line; figure 5.1.1 p. 78, line 1—p. 85, line 28; figure 7.2.1. |
Grgic et al.; “Policy-based charging in IMS for multimedia services with negotiable QoS requirements”, CAD Systems in Microelectronics, 2009. CADSM 200910th International Conference—The Experience of Designing and Application of, IEEE, Piscataway, NJ, USA, Jun. 8, 2009, pp. 257-264, XP031514058. |
International Search Report and Written Opinion corresponding to International Application No. PCT/SE2010/051205; Date of Mailing: Jul. 13, 2011; pages. |
Kuhne et al: “Architecture for a service-oriented and convergent charging in 3G mobile networkds and beyond”, 6th IEEE Conference on 3G and Beyond (05/11182), vol. 2005, Jan. 1, 2005, pp. 517-521, XP55001530. |
International Preliminary Report on Patentability for corresponding application No. PCT/SE2010/051205, mailed Mar. 9, 2012, 46 pages. |
Number | Date | Country | |
---|---|---|---|
20110161216 A1 | Jun 2011 | US |