Control of time limit triggers for offline charging

Systems and methods for controlling time limit triggers for offline charging. In one embodiment, a network element that serves an active session for User Equipment (UE) includes a Charging Trigger Function (CTF) that detect expiry of a time limit for triggering an interim accounting request to an offline charging system during the active session. The CTF then identifies a data usage by the UE during the time limit, and determines if the data usage by the UE during the time limit exceeds a threshold. If the data usage exceeds the threshold, then the CTF sends the interim accounting request to the offline charging system responsive to expiry of the time limit. If the data usage does not exceed the threshold, then the CTF stops the interim accounting request from being sent to the offline charging system responsive to expiry of the time limit.

FIELD OF THE INVENTION

The invention is related to the field of communications and, in particular, to offline charging in communication networks.

BACKGROUND

Service providers are able to provide numerous voice and data services to end users (also referred to as subscribers, user equipment, wireless devices, etc.). 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, IP-TV, etc. The data services are managed by a Packet-Switched (PS) core network, which interfaces the end user with one or more external Packet Data Networks (PDN), such as the Internet. When accessing data services, the sessions established by end users are typically much longer in duration than traditional voice calls. For instance, a typical voice call may last ten minutes or less, while data sessions for surfing the Internet, watching IP-TV, playing online games, etc., may last for many hours or even days.

PS core networks, such as the Evolved Packet Core (EPC), allow end users to engage in data sessions that are “always on”. “Always-on” sessions may be active over the PS core network for several hours or several days. Although the session is active, there may be idle periods where the end user's device is not sending or receiving data. For example, if an end user is logged into an online game, a session will be active while the end user is logged in. But, the end user may not play the game continuously when logged in, so consequently there will be idle periods during the gaming session where the end user device is not actually consuming data.

End users that are served by a PS core network may subscribe to offline charging. Offline charging refers to a charging method where charging information for network resource usage is collected concurrently with the resource usage. When network elements in the PS core network provide services for a session, the network elements are configured to report charging events to an Offline Charging System (OFCS) when certain trigger conditions are met. Some examples of triggers for charging events are data volume limits and time limits. For a data volume limit, a charging event is triggered if the volume of downlink data and/or uplink data for an end user exceeds a maximum. For example, the downlink limit may be 100 MB, and the uplink limit may be 10 MB. For the time limit, a charging event is triggered if a time limit has expired since the last charging event. For example, the time limit may be 15 minutes. Other types of trigger conditions may be specified, such as described in 3GPP TS 32.251.

When trigger conditions are detected, the network element reports the charging event to the OFCS in the form an accounting request, such as a Diameter Rf Accounting Request (ACR). The OFCS then generates Charging Data Records (CDR) for the each of the network elements based on the accounting requests that are received. At some point in time, the OFCS passes the CDRs to the billing domain where a bill is generated at the end of a billing cycle (e.g., a monthly billing cycle). The network operator can then send out a bill to the end user that specifies the usage by the end user during the billing cycle.

Unfortunately, sessions that are “always on” can cause problems to network operators when charging for these sessions.

SUMMARY

Embodiments described herein control whether network elements are allowed to report charging events to an OFCS upon detection of a time limit trigger. Traditionally, a network element would report a charging event to the OFCS when the time limit trigger expires. This works effectively when an end user is actively consuming data in the downlink or uplink direction, because the network element would be reporting actual use of data (i.e., data consumption) to the OFCS. However, sessions may have periods of idle time where the end user is not actively consuming data. Even during these idle periods, a traditional network element will periodically report charging events to the OFCS based on the time limit trigger (e.g., every fifteen (15) minutes, as predicated by the value of the Accounting Interim Interval set for the deployment) even though there is no change in data or “insignificant” data usage to report. For instance, a network element may send multiple interim accounting requests to the OFCS that show zero (0) bytes of consumption in the downlink and uplink directions. Unfortunately, the reporting zero or very low data usage by network elements to an OFCS wastes network resources.

In the embodiments described herein, before a network element reports a charging event to an OFCS based on a time limit trigger, the network element identifies the amount of data consumed during the time limit. If the data consumed is insignificant, such as zero (0) bytes, a few kB, or below a threshold amount of bytes, then the network element ignores the time limit trigger and does not report a charging event to the OFCS. If the data consumed is more than an insignificant amount (i.e., at or above a threshold amount of bytes), such as 1 MB, then the network element processes the time limit trigger and reports a charging event to the OFCS. The threshold amount of data considered “insignificant” is configurable by the network operator. The network element is therefore able to intelligently report charging events to the OFCS when there is data usage that is worth reporting to the OFCS, which saves network resources.

One embodiment comprises a network element of a communication network that serves an active session for User Equipment (UE). The network element includes a Charging Trigger Function (CTF) configured to detect expiry of a time limit for triggering an interim accounting request to an offline charging system during the active session, to identify a data usage by the UE during the time limit, and to determine if the data usage by the UE during the time limit exceeds a threshold. If the data usage exceeds the threshold, then the CTF is configured to send the interim accounting request to the offline charging system responsive to expiry of the time limit. If the data usage does not exceed the threshold, then the CTF is configured to stop the interim accounting request from being sent to the offline charging system responsive to expiry of the time limit.

In another embodiment, the threshold is less than a data volume limit for triggering other interim accounting requests to the offline charging system.

In another embodiment, the threshold includes a downlink threshold and an uplink threshold.

In another embodiment, the interim accounting request comprise a Diameter Rf Accounting Request (ACR)[Interim].

In another embodiment, the communication network includes an Evolved Packet Core (EPC), and the network element comprises one of a Serving Gateway (S-GW) and a Packet Data Network Gateway (PDN-GW).

Another embodiment comprises a method operable in a network element of a communication network that serves an active session for User Equipment (UE). The method includes the steps of detecting expiry of a time limit for triggering an interim accounting request to an offline charging system during the active session, identifying a data usage by the UE during the time limit, and determining if the data usage by the UE during the time limit exceeds a threshold. If the data usage exceeds the threshold, then the method includes sending the interim accounting request from the network element to the offline charging system responsive to expiry of the time limit. If the data usage does not exceed the threshold, then the method includes stopping the interim accounting request from being sent to the offline charging system responsive to expiry of the time limit.

Another embodiment comprises a non-transitory computer-readable medium that stores program instructions for providing offline charging in a network element of a communication network that serves an active session for User Equipment (UE). The program instructions, when executed by a computer system, cause the computer system to detect expiry of a time limit for triggering an interim accounting request to an offline charging system during the active session, identify a data usage by the UE during the time limit, and determine if the data usage by the UE during the time limit exceeds a threshold. If the data usage exceeds the threshold, then the computer system sends the interim accounting request to the offline charging system responsive to expiry of the time limit. If the data usage does not exceed the threshold, then the computer system stops the interim accounting request from being sent to the offline charging system responsive to expiry of the time limit.

Other exemplary embodiments may be described below.

DESCRIPTION OF EMBODIMENTS

FIG. 1illustrates a communication network100in an exemplary embodiment. Communication network100may represent a Long Term Evolution (LTE) network, an IP Multimedia Subsystem (IMS) network, or another type of Third Generation (3G) or Fourth Generation (4G) communication network. Network100includes a Packet-Switched (PS) core network110that provides various services to end users. One example of PS core network110is an Evolved Packet Core (EPC) network. In this embodiment, PS core network110includes network elements112-113that are each able to provide services. One example of network element112may be a Serving Gateway (S-GW) of an EPC network as described in the LTE standards. One example of network element113may be a Packet Data Network Gateway (PDN-GW) of an EPC network as described in the LTE standards. Other examples of network elements112-113may be a Mobility Management Entity (MME), an Application Server (AS), etc. PS core network110may include many more network elements that are not shown inFIG. 1for ease of illustration.

PS core network110provides data services to User Equipment (UE)120(and other UEs not shown). UE120may be a mobile device (e.g., a mobile phone), a computer, a tablet, etc. UE120is able to access PS core network110through access network130. Access network130comprises any type of network that interfaces UEs with PS core network110. One example of access network130is a Radio Access Network (RAN), such as a UMTS Terrestrial Radio Access Network (UTRAN), an enhanced UTRAN (E-UTRAN), an Interworking-Wireless Local Area Network (I-WLAN), etc. PS core network110also connects to one or more external Packet Data Networks (PDN)140, such as the internet.

Within PS core network110, network elements112-113each include a Charging Trigger Function (CTF)116-117, respectively. A CTF comprises any entity that generates charging events based on the observation of network resource usage. The CTF is the focal point for collecting information pertaining to chargeable events within a network element, assembling this information into matching charging events, and sending these charging events towards a charging function in the form of accounting requests. A CTF is implemented in each network element or service element that provides charging information. Therefore, CTF116is illustrated inFIG. 1as being embedded in network element112, and CTF117is illustrated inFIG. 1as being embedded in network element113.

PS core network110also includes an Offline Charging System (OFCS)150. OFCS150comprises any system, server, or function operable to provide offline charging for services/sessions accessed by end users, such as UE120. OFCS150includes a group of peer charging functions152-154used for offline charging. A charging function152-154is configured to receive accounting requests (i.e., charging events) from network elements, and use the charging information contained in the accounting requests to construct Charging Data Records (CDRs). One example of a charging function152-154is a Charging Data Function (CDF) as defined by the 3GPP in TS 32.240 (Release 6). The purpose of offline charging is to transform the charging information into CDRs that are post-processed within a Billing Domain (BD) for the purpose of generating bills.

Offline charging can be categorized into two distinct classes: event-based charging and session-based charging. In event-based charging, a chargeable event is defined as a single end-user-to-network transaction, such as sending a multimedia message. The single transaction is mapped to a charging event, which results in a single CDR. In session-based charging, a user session is established resulting in the generation of multiple chargeable/charging events and the generation of one or more CDRs. In session-based charging, at least two charging events are needed for each session. One charging event describes the start of the session, and the other charging event describes the end of the session. Multiple other charging events, so called interim charging events, may also be utilized to describe changes to session characteristics (i.e., change of charging conditions), when a time limit is reached, when a volume limit is reached, etc.

The CTFs116-117described herein store charging characteristics for offline charging. The charging characteristics may be provided by a database, such as a Home Subscriber Server (HSS), or may be default characteristics. The charging characteristics define triggers for reporting charging events to OFCS150. One of the triggers that may be stored by a CTF is a time limit between charging events. The CTF maintains a counter of the time since it last reported an accounting request to OFCS150, and is configured to trigger or report an interim accounting request to OFCS150upon expiry of the time limit. Another one of the triggers that may be stored by a CTF is a data volume limit. The CTF maintains a counter of the amount of data consumed (downlink and/or uplink) for an end user during a session, and is configured to trigger an interim accounting request to OFCS150if the volume of data consumed exceeds the data volume limit. The charging characteristics may include other triggers for charging events that are not discussed herein.

According to the embodiments described herein, CTFs116-117are configured to control whether or not interim accounting requests are triggered to OFCS150due to expiry of the time limit based also on a data threshold defined in the charging characteristics. Instead of automatically reporting an interim accounting request to OFCS150when the time limit expires, CTFs116-117determine whether data usage during the time limit exceeds a threshold. CTFs116-117store a data threshold that is associated with the time limit trigger. The data threshold indicates a minimum amount of data that has to have been consumed upon expiry of the time limit (i.e., minimum amount of data consumed within the duration of the time limit) before an interim accounting request is triggered toward OFCS150. The data threshold may be set at a number between zero (0) bytes and a chosen amount of data. The data threshold may be limited to a maximum of the amount of data defined for the data volume limit. For example, a data volume limit may indicate a downlink limit of 100 MB and an uplink limit of 10 MB for triggering an interim accounting request. The data threshold defined for the time limit trigger may set to be a percentage of the downlink and uplink limits, such as 100 kB downlink and 10 kB uplink, or may be set to given values, such as 50 kB downlink and 5 kB uplink. The data threshold(s) defined for the time limit trigger may be configurable by the network operator.

InFIG. 1, assume that UE120registers with network100in order to receive services, and requests a data session. A session as described herein may be referred to as an IP Connectivity Access Network (IP-CAN) session. An IP-CAN session is an association between UE120represented by an IPv4 address and/or an IPv6 prefix, and PDN140. An IP-CAN session may incorporate one or more IP-CAN bearers. An IP-CAN bearer is an IP transmission path of defined capacity, delay and bit error rate, etc. Each IP-CAN bearer may be made up of one or more Service Data Flows (SDF), which is a flow of packets.

If a session initiates and network element112activates a bearer for the session (e.g., an IP-CAN bearer), then CTF116of network element112identifies an initial chargeable event responsive to the start of the session. The start of a “session” may refer to the start of an IP-CAN bearer, the start of a service data flow for an IP-CAN bearer, the start of an IP Multimedia Subsystem (IMS) session, etc. CTF116generates an initial accounting request for the session responsive to the initial chargeable event, and transmits the initial accounting request to OFCS150to initiate session-based offline charging for the session. The initial accounting request generated by CTF116may comprise a Diameter Rf ACR[Start]. In response to the initial accounting request, OFCS150will open a Charging Data Record (CDR) for network element112.

As network element112continues to serve the session, CTF116may encounter other trigger conditions for reporting interim charging events to OFCS150.FIG. 2indicates how CTF116controls whether interim accounting requests are sent to OFCS150when a trigger condition is met.

FIG. 2is a flow chart illustrating a method200of controlling transmission of interim accounting requests to OFCS150in an exemplary embodiment. The steps of method200will be described with reference to network element112inFIG. 1, but those skilled in the art will appreciate that method200may be performed in other systems. Also, the steps of the flow chart inFIG. 2are not all inclusive and may include other steps not shown, and further, the steps may be performed in an alternative order.

In step202, CTF116of network element112detects expiry of the time limit for triggering an interim accounting event to OFCS150during the active session. In step204, CTF116identifies the data usage by UE120during the time limit. As stated above, CTF116maintains a volume count of the data consumed during the active session (separated for downlink and uplink). CTF116can therefore determine the data usage of UE120during the time limit specified in the charging characteristics. CTF116then determines if the data usage by UE120during the time limit exceeds the data threshold associated with the trigger in step206.

If the data usage exceeds the data threshold, then CTF116sends an interim accounting request to OFCS150responsive to expiry of the time limit. The interim accounting request may comprise a Diameter Rf ACR[Interim], a Diameter Ga CDR, etc. The interim accounting request may include details such as a Subscription-ID (e.g., IMSI), a Charging-ID, an address for network element112, a container identifying the volume count (separated for uplink and downlink traffic) for the (IP-CAN) bearer, etc.

If the data usage does not exceed the threshold, then CTF116does not send the interim accounting request to OFCS150responsive to expiry of the time limit. Thus, CTF116does not report the interim accounting request to OFCS150if the data usage of UE120does not exceed the data threshold associated with the time limit trigger, even though time related conditions for the trigger have been met. Traditionally, a CTF would report the interim accounting request to OFCS150automatically if conditions for a time limit trigger have been met. However, CTF116described herein intelligently reports an interim accounting request to OFCS150if the data usage of UE120exceeds the data threshold upon expiry of a time limit. It is understood that CTF116establishes an agreement with OFCS150a priori so that the OFCS150does not time out the session upon non-receipt of the periodic interim accounting requests.

The provided methodology and trigger advantageously saves network resources, because some conventional interim accounting requests would report that no data usage or only an insignificant amount of data usage, such as during an idle period of the session. It is essentially a waste of resources to report “empty” interim accounting requests to an OFCS. By defining the data threshold as described herein, a CTF sends interim accounting requests to OFCS150that report more than an insignificant amount of data usage (i.e., data usage that exceeds the data threshold), so that it is worthwhile to use network resources to report the interim accounting requests.

Example

FIG. 3illustrates a Long Term Evolution (LTE) network300in an exemplary embodiment. LTE network300includes an Evolved Packet Core (EPC) network310in which a UE320is subscribed to a service plan. EPC network310includes a Serving Gateway (S-GW)312, a PDN Gateway (PDN-GW)313, a Mobility Management Entity (MME)314, and a Home Subscriber Server (HSS)315. The illustrated network elements of an EPC network are shown as an example, and EPC network may include other network elements not shown.

S-GW312is the gateway that terminates the interface from EPC network310towards E-UTRAN330. S-GW312is responsible for transferring the data packets for a session across the user plane. PDN-GW313is the gateway that terminates the interface from EPC network310to an external Packet Data Network (PDN)340. PDN-GW313is responsible for connectivity between UE320and PDN340by being the entry/exit point of traffic. MME314is responsible for tracking the location of UE320, and paging UE320for communications. HSS315is a central database that stores subscription information for end users. For example, HSS315may store subscriber profiles that indicate which services an end user subscribes to in EPC network310.

The following example illustrates an offline charging system within LTE network300. To implement offline charging, a Charging Trigger Function (CTF)316is imbedded in S-GW312, and a CTF317is embedded in PDN-GW313. LTE network300also includes offline charging system (OFCS)350. CTFs316-317are connected to OFCS350over a Diameter Rf reference point. OFCS350is also connected to the billing domain360over a Diameter Gx reference point.

FIG. 4is a message diagram illustrating an example of controlling whether interim charging events are reported to OFCS350in an exemplary embodiment. In this example, assume that an IP-CAN bearer is activated for an IP-CAN session involving UE320. S-GW312is involved in activating the IP-CAN session. CTF316within S-GW312identifies a chargeable event when the IP-CAN session begins. Thus, CTF316generates a Diameter Rf ACR[Start], and sends the ACR [Start] to OFCS350. In response to the ACR[Start], OFCS350opens a CDR for the IP-CAN bearer for S-GW312, and replies back to CTF316with a Diameter Rf Accounting Answer, e.g., ACA[Start].

Between the time the IP-CAN bearer is activated and the time when the IP-CAN bearer is torn down, CTF316may encounter triggering conditions for reporting interim charging events to OFCS350. One of the triggers in the charging characteristics for reporting interim charging events to OFCS350is a time limit. Therefore, CTF316will maintain a counter based on the last time instance when an ACR[Start] or ACR[Interim] was sent to OFCS350. When CTF316detects expiry of the time limit defined in the charging characteristics, CTF316does not automatically send a Diameter Rf ACR[Interim] to OFCS350. Instead, CTF316identifies the data usage by UE320during the time limit by monitoring a volume counter for the IP-CAN bearer. CTF316then determines if the data usage by UE320exceeds a threshold during the time limit. The threshold may be some configurable percentage of the data volume limit specified in the charging characteristics (e.g., data volume limit>threshold≧0) or a given amount of data which may be configurable. If the data usage during the time limit exceeds the threshold, then CTF316sends a Diameter Rf ACR[Interim] to OFCS350responsive to expiry of the time limit. If the data usage does not exceed the threshold during the time limit, then CTF316does not send a Diameter Rf ACR[Interim] to OFCS350responsive to expiry of the time limit.

The assumption at this point is that the data usage of UE320does not exceed the threshold (e.g., there is an idle period during the active session). Because the data usage was below the threshold, CTF316does not report a Diameter Rf ACR[Interim] to OFCS350even though the time limit conditions for the trigger have been met. When CTF316does not send a Diameter Rf ACR[Interim] to OFCS350upon expiry of the time limit, CTF316also does not increment the sequence number stored for the ACRs. CTF316will not increment the sequence number until another ACR[Interim] is actually sent to OFCS350.

CTF316then continues to monitor the triggers defined in the charging characteristics while S-GW312serves the IP-CAN session. If CTF316again detects that the time limit has expired for sending an ACR[Interim], then CTF316identifies the data usage by UE320during this time limit. CTF316then determines if the data usage by UE320exceeds the threshold during the time limit. If the data usage during the time limit exceeds the threshold, then CTF316sends a Diameter Rf ACR[Interim] to OFCS350responsive to expiry of the time limit. If the data usage does not exceed the threshold during the time limit, then CTF316does not send a Diameter Rf ACR[Interim] to OFCS350responsive to expiry of the time limit.

The assumption at this point is that the data usage of UE320exceeds the threshold (e.g., there is consumption of data of a “significant” amount during the IP-CAN session). Because the data usage was above the threshold, CTF316sends a Diameter Rf ACR[Interim] to OFCS350. OFCS350will then update the CDR for the session based on charging information included in the ACR[Interim].

CTF316will continue to monitor the session for chargeable events that trigger an ACR[Interim]. If conditions for the time limit trigger are met again, then CTF316will operate as described above to determine whether or not to send an ACR[Interim] to OFCS350.