CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit under 35 U.S.C. § 1 19(e) to U.S. Provisional Application No. 62/433,414, entitled "ONLINE CHARGING MECHANISMS DURING OCS OUTAGE," filed on December 13, 2016, the contents of which are incorporated by reference herein in its entirety.

FIELD OF INVENTION

[0002] The invention generally relates to telecommunications systems and, in particular, to "machine to machine" (M2M) and radio access network (RAN) communication systems.

BACKGROUND

[0003] Service providers use online charging servers to ensure that customers have enough quota or grants (e.g., for data) before a service request can be granted and/or services can be provided. In a typical system, user equipment requests to use a network resource, such as data, time, credits, quality of service (QOS), etc. A gateway communicates with an online charging server ("OCS") to identify an allocation of the requested resource. The OCS then communicates the allocation to the gateway, which then assists in providing services based on the desired allocation. The gateway can request updates from the OCS over the course of the session.

[0004] This process works well when the OCS is online and functioning. However, when the OCS has an outage or otherwise becomes non-responsive, user equipment can be denied service either before or during a session. While reducing or eliminating OCS non- responsiveness can help to mitigate this problem, a solution is needed that accommodates OCS non-responsiveness without interruption or denial of service to users.

SUMMARY OF THE INVENTION

[0005] Methods described herein can include receiving, at a gateway (e.g., a packet gateway "PGW"), a request from user equipment to initiate a session with, and request a quota from, an online charging server ("OCS"). Via the gateway, the online charging server may be determined (e.g., detected) to be non-responsive, and in response, a default quota is automatically granted to the user equipment. The default quota can be based on an identifier of a device, such as an access point name (APN), that is associated with the user equipment. In some implementations, the session is deleted after the automatic grant of the default quota to the user equipment.

[0006] In some embodiments, a method also includes transmitting an update to the online charging server after granting the default quota to the user equipment, the update comprising an amount of data consumed by the user equipment.

[0007] In some embodiments, a method also includes sending a request for an online quota (e.g., a for time, events, inbound/outbound volume, etc.) to the online charging server after automatically granting a default quota to the user equipment.

[0008] In some embodiments, a method also includes sending a request for an online quota to the online charging server before detecting, via the gateway, that the online charging server is non-responsive. The online quota can be received at the gateway from the online charging server before detecting, via the gateway, that the online charging server is non- responsive. In some such embodiments, an update is transmitted to the online charging server after the grant of the default quota to the user equipment, and the update can include an amount of data consumed by the user equipment.

[0009] In some embodiments, a method also includes initiating the session between the gateway and the online charging server and receiving an online quota from the online charging server. In some such implementations, the detection of the online charging server being non-responsive occurs after receiving the online quota from the online charging server.

[0010] In some aspects, a disclosed method of accommodating non-responsiveness of an online charging node in a networked system includes receiving a request from a subscriber; identifying that an online charging node is non-responsive; assigning a default quota to the subscriber, the default quota defining a service usage threshold for the subscriber; and providing service to the subscriber based on the default quota.

[0011] In some embodiments, the online charging node comprises an online charging server (OCS).

[0012] In some embodiments, the identifying and assigning steps are performed by a charging enforcement node, and wherein the online charging node is configured to provide a control message to the charging enforcement node. In some embodiments, the charging enforcement node comprises a packet gateway (PGW). In some embodiments, the charging enforcement node comprise a gateway GPRS support node (GGSN). [0013] In some embodiments, the step of identifying that the online charging node is non- responsive includes detecting a lack of a heartbeat from the online charging node. In some embodiments, the step of identifying that the online charging node is non-responsive comprises identifying a timeout of the online charging node.

[0014] In some embodiments, the method further includes assigning the default quota to a session for the subscriber. In some embodiments, the method further includes assigning the default quota to at least one additional session.

[0015] In some embodiments, the providing service to the subscriber based on the default quota includes tracking a usage associated with the service. In some embodiments, the method further includes identifying that the online charging node has become responsive; and reconciling with the online charging node the usage associated with the service.

[0016] In other aspects, a disclosed method of accommodating non-responsiveness of an online charging node in a networked system includes receiving a request for service from a subscriber; transmitting a message to an online charging node to initiate a session for the subscriber; identifying that the online charging node is non-responsive; assigning a default quota to the subscriber, the default quota defining a service usage threshold for the subscriber; and providing service to the subscriber based on the default quota.

[0017] In some embodiments the online charging node comprises an online charging server (OCS).

[0018] In some embodiments, the transmitting, identifying, and assigning steps are performed by a charging enforcement node, and wherein the online charging node is configured to provide a control message to the charging enforcement node. In some embodiments, the charging enforcement node comprises a packet gateway (PGW). In some embodiments, wherein the charging enforcement node comprise a gateway GPRS support node (GGSN).

[0019] In some embodiments, the step of identifying that the online charging node is non- responsive includes detecting a lack of a heartbeat from the online charging node. In some embodiments, the step of identifying that the online charging node is non-responsive comprises identifying a timeout of the online charging node by identifying that a control message has not been received within a predetermined amount of time.

[0020] In some embodiments, the method further includes assigning the default quota to a session for the subscriber. In some embodiments, the method further includes assigning the default quota to at least one additional session. [0021] In some embodiments, the providing service to the subscriber based on the default quota includes tracking a usage associated with the service. In some embodiments, the method further includes identifying that the online charging node has become responsive; and reconciling with the online charging node the usage associated with the service.

[0022] In some aspects, a disclosed method of accommodating non-responsiveness of an online charging node in a networked system includes receiving a request for service from a subscriber; transmitting a message to an online charging node to initiate a session for the subscriber; receiving a control message from the online charging node; providing service to the subscriber based on the control message; identifying that the online charging node is non- responsive; assigning a default quota to the subscriber, the default quota defining a service usage threshold for the subscriber; and providing continued service to the subscriber based on the default quota.

[0023] In some embodiments, the online charging node comprises an online charging server (OCS).

[0024] In some embodiments, the transmitting, receiving, identifying, and assigning steps are performed by a charging enforcement node, and wherein the online charging node is configured to provide the control message to the charging enforcement node.s

[0025] In some embodiments, the charging enforcement node comprises a packet gateway (PGW). In some embodiments, the charging enforcement node comprise a gateway GPRS support node (GGSN).

[0026] In some embodiments, the step of identifying that the online charging node is non- responsive includes detecting a lack of a heartbeat from the online charging node. In some embodiments, the step of identifying that the online charging node is non-responsive comprises identifying a timeout of the online charging node by identifying that a control message has not been received within a predetermined amount of time.

[0027] In some embodiments, the method further includes assigning the default quota to a session for the subscriber. In some embodiments, the method further includes assigning the default quota to at least one additional session.

[0028] In some embodiments, the providing service to the subscriber based on the default quota includes tracking a usage associated with the service. In some embodiments, the method further includes identifying that the online charging node has become responsive; and reconciling with the online charging node the usage associated with the service. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] For a more complete understanding of various embodiments of the disclosed subject matter, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

[0030] Figure 1 is a flow diagram illustrating an online charging server (OCS) call flow in which the OCS is online and continuously functioning.

[0031] Figure 2 is a flow diagram illustrating an OCS call flow in which the OCS is initially non-responsive and subsequently becomes responsive during a session.

[0032] Figure 3 is a flow diagram illustrating an OCS call flow in which the OCS is non- responsive and remains non-responsive throughout a session.

[0033] Figure 4 is a flow diagram illustrating an OCS call flow in which the OCS is initially online, becomes non-responsive, and subsequently becomes responsive ("rejoins") during a session.

[0034] Figure 5 is a flow diagram illustrating an OCS call flow in which the OCS is initially online, and subsequently becomes non-responsive and remains non-responsive throughout a session.

DETAILED DESCRIPTION

[0035] Some embodiments described herein relate to methods for coping with server non- responsiveness in online charging system contexts, for example to facilitate delayed or offline delivery of OCS quota data and/or default quota data. Such online charging system contexts can include one or more Diameter credit-control applications in which end users (or "subscribers") request allocations of data, time, credits, etc. from an OCS as part of a service that he/she subscribes to. In some such traditional systems, if the OCS has an outage or otherwise becomes non-responsive, subscribers have been denied service. Attempts to mitigate these situations by traditional providers have often focused on reducing or eliminating the OCS downtime. By contrast, methods and systems described herein are designed to accommodate server non-responsiveness such that a subscriber experiences continuous service, and an accounting of quotas requested and/or used can be reconciled with the OCS once it comes back online. In some implementations, the quotas can be successfully reconciled with the OCS regardless of whether it comes back online during a session, after a session has terminated, or not at all. [0036] In some embodiments, a "session" includes communication between a packet gateway (PGW) and an OCS. The PGW can be configured to identify that the OCS has become non-responsive by detecting that the Diameter "heartbeat" (e.g., watchdog messages, which can occur, for example, every 2-3 minutes) of the OCS has stopped, based on a transaction timeout (e.g., no response detected after, for example, 1-2 seconds), or based on any other method of identifying non-responsiveness. Non-responsiveness can include the server being unavailable, unreachable, offline, timed out, disconnected, overloaded, malfunctioning, shut down, in an outage condition, or any other type of non-responsiveness.

[0037] Figure 1 is a flow diagram illustrating an online charging server (OCS) call flow 100 (illustrated herein to include, but not limited to, a Gy interface), in which the OCS 104 is online and continuously functioning. As shown in Figure 1, the PGW 102 receives a "create session" request 106 (e.g., from user equipment/subscriber) and transmits an initial credit control request ("Gy-CCR-I") message 108 to the OCS 104. The Gy-CCR-I message 108 is a type of credit control request message used when a session based on credit control is required under the "Diameter" protocol. More specifically, the Gy-CCR-I message 108 is an initial message sent at the beginning of the session that must be sent before service is allowed to the user equipment. The PGW 102 receives an initial credit control acceptance ("Gy-CCA-I") message 110 back from the OCS 104 in response to the Gy-CCR-I message 108 acknowledging the GyCCR-I message 108 and indicating an acceptance or failure of the request. In some embodiments, the acceptance or failure of the request depends on whether the subscriber has enough credits. Based on the received Gy-CCA-I message 110, the PGW 102 determines that an OCS quota has been granted (112).

[0038] Figure 2 is a flow diagram illustrating an OCS call flow 200 (illustrated herein to include, but not limited to, a Gy interface), in which the OCS 204 is initially non- responsiveand subsequently becomes reachable during a session. As shown in Figure 2, the PGW 202, in response to a "create session" request 206 (e.g., from user equipment/a subscriber), attempts to transmit a Gy-CCR-I message 208A to the OCS 204, but the transmission does not reach the OCS 204 because it is non-responsive (e.g., is experiencing an outage or the network route is not available). In response to this failed transmission, the PGW 202 automatically grants a "default quota" 211 such that the end user (also "requestor" or subscriber) receives continuous service notwithstanding the OCS 204 being non- responsive. In some embodiments, the default quota can be customized to the requestor, for example based upon a database of preauthorized quota amounts, a history of OCS quota grants, etc. The requestor (and/or a device associated therewith) can be identified, for example, by his "access point name" (APN), and/or by a set of "policy and charging rules functions" (PCRFs) that are accessible to the PGW 202. For example, the PCRF can trigger a pre-configured set of parameters for a given APN. The PCRF can be a surrogate for saying that a subscriber is in a lower class and should be configured to have a lower default quota. The PGW can use any data available that is associated with an individual user or group of users in order to set the default quota.

[0039] Different network providers may choose to grant different default quotas from other network providers. Different network providers may also implement different selection criteria to choose among multiple default quotas depending on desired operating characteristics of the network. Network providers may choose small default quotas to avoid leakage. Conversely, network providers may choose large default quotas to avoid the risk of service interruption.

[0040] Subsequent to the granting of the default quota 211 by the PGW 202 (for example, upon detection by the PGW 202 that the OCS 204 is once again online, e.g., via a detecting a heartbeat from OCS 204 and/or receiving a response to a message), the PGW 202 can again transmit a Gy-CCR-I message (208B) to the OCS 204, and the transmission reaches the OCS 204 because it is online. A Gy-CCA-I message 210 is then sent back to the PGW 202 by the OCS 204. Next, according to some embodiments (in which the OCS 204 is configured to accept default quota reporting) the PGW 202 "updates" the OCS 204 by sending an update request message "Gy-CCR-U" 214 to the OCS 204. The Gy-CCR-U message 214 is an update request message that can be sent once a quota is reached, and can report the actual usage for all relevant statistics. The OCS 204 then acknowledges receipt of the Gy-CCR-U message 214 by sending an update acceptance message "Gy-CCA-U" 216 to the PGW 202. The Gy-CCA-U message 216 can indicate a new monitoring threshold, service, activation, or service deactivation.

[0041] In some embodiments, the full usage of the requester is reported to an operator via the update sent to the OCS 204, while in other embodiments, only the fact that the requestor has utilized the full amount of an already approved quota is reported to an operator via the update sent to the OCS 204. For example, according to an embodiment, the OCS 204 may not be configured to accept quotas provided from other sources, e.g., the PGW 202. The PGW 202 can reconcile the usage by the subscriber during the period of non-responsiveness without providing information about the default quota to the OCS 204. The PGW 202 can reconcile usage during the period of non-responsiveness by reporting usage based on quotas provided by the OCS before or after the period of non-responsiveness of the OCS 204. If the usage during the period of non-responsiveness of the OCS 204 exceeded a quota provided by the OCS 204, additional quotas can be requested until the full usage has been reported. Alternatively, usage beyond an approved quota can go unreported, or partially reported.

[0042] According to an embodiment, the OCS 204 may be configured to accept quotas provided from other sources, e.g., the PGW 202. The PGW 202 can reconcile usage during the period of non-responsiveness of the OCS 204 by providing the default quota to the OCS 204. According to another embodiment, the OCS 204 may be configured to accept usage reports without quotas from other sources, e.g., the PGW 202. The PGW 202 can reconcile usage during the period of non-responsiveness of the OCS 204 by reporting the full usage to the OCS 204.

[0043] Figure 3 is a flow diagram illustrating an OCS call flow 300 (illustrated herein to include, but not limited to, a Gy interface), in which the OCS 304 is non-responsive and remains non-responsive throughout a session. As shown in Figure 3, the PGW 302, in response to a "create session" request 306 (e.g., from user equipment/a subscriber), attempts to transmit a Gy-CCR-I message 308 to the OCS 304, but the transmission does not reach the OCS 304 because it is non-responsive (e.g., is experiencing an outage or it is not available on the network). In response to this failed transmission, the PGW 302 (as discussed above with reference to Figure 2) automatically grants a "default quota" 311 such that the requestor receives continuous service notwithstanding the OCS 304 being non-responsive. As described above, the default quota can be customized to the requestor, for example based upon a database of preauthorized quota amounts, a history of OCS quota grants, etc. The requestor can be identified, for example, by his "access point name" (APN), and/or by a set of "policy and charging rules functions" (PCRFs) that are accessible to the PGW 302. For example, the PCR can trigger a pre-configured set of parameters for a given APN. The PCRF can be a surrogate for saying that a subscriber is in a lower class and should be configured to have a lower default quota. Subsequent to the granting of the default quota 311 by the PGW 302, the PGW 302 can delete the session 318, and the default quota usage can be written to a local charging data record (CDR) (e.g., an offline interface, another reachable online interface, or any server designated for data not yet communicated) which can be used to reconcile usage to the OCS (e.g., as discussed above with respect to Figure 2) or other system(s), and/or transmitted via a file transfer protocol (FTP), or any other method of communicating and/or storing default quota usage.

[0044] Figure 4 is a flow diagram illustrating an OCS call flow (illustrated herein to include, but not limited to, a Gy interface), in which the OCS 404 is initially online, becomes non-responsive, and subsequently becomes responsive ("rejoins") during a session. As shown in Figure 4, the PGW 402 receives a "create session" request 406 (e.g., from user equipment/a subscriber) and transmits a credit control request ("Gy-CCR-I") message 408 to the OCS 404, and receives a credit control acceptance ("Gy-CCA-I") message 410 back from the OCS 404. Based on the received Gy-CCA-I message 410, the PGW 402 determines that an OCS quota has been granted (412). Subsequent to the granting of the OCS quota 412, the PGW 402 may attempt to send an update Gy-CCR-U message 414A to the OCS 404 (e.g., to report that the subscriber who originally requested the quota referenced by Gy-CCR-I 408 used more than the allocation permitted by the previously granted OCS quota 412 or any other message to the OCS 404 for a different purpose), and finds that the OCS is unavailable. In response to this failed update transmission, the PGW 402 automatically grants a default quota 411 such that the user equipment's service remains uninterrupted. Subsequent to the PGW 402' s granting of the default quota 411, the PGW 402 may again attempt to transmit an update Gy-CCR-U message (414B) to the OCS 404, at which time the OCS 404 may have rejoined the session (i.e., came back online). The Gy-CCR-U message (414B) can include data regarding the quota that was used by the requestor/subscriber while the OCS 404 was non-responsive as discussed above with respect to Figure 2. The OCS may, in turn, acknowledge receipt of the update(s) by sending an update acceptance message "Gy-CCA-U" 416 to the PGW 402.

[0045] Alternatively, subsequent to the PGW 402' s granting of the default quota 411, the PGW 402 may detect a heartbeat from the OCS 404 indicating that the OCS 404 has become reachable. The PGW 402 may then reconcile with the OCS 404 immediately using the reconciliation methods discussed herein depending on the configuration of the OCS 404, such as reporting usage or reporting the default quota 411. Alternatively, the PGW 402 may wait to reconcile with the OCS 404 until a later time, such as when the default quota 411 has been met.

[0046] Figure 5 is a flow diagram illustrating an OCS call flow 500 (illustrated herein to include, but not limited to, a Gy interface), in which the OCS 504 is initially online, and subsequently goes non-responsive and remains non-responsive throughout a session. As shown in Figure 5, the PGW 502 receives a "create session" request 506 (e.g., from user equipment/subscriber) and transmits a credit control request ("Gy-CCR-I") message 508 to the OCS 504, and receives a credit control acceptance ("Gy-CCA-I") message 510 back from the OCS 504. Based on the received Gy-CCA-I message 510, the PGW 502 determines that an OCS quota has been granted (512). Subsequent to the granting of the OCS quota 512, the PGW 502 may attempt to send an update Gy-CCR-U message 514 to the OCS 504 (e.g., to report that the subscriber who originally requested the quota referenced by Gy-CCR-I 508 used more than the allocation permitted by the previously granted OCS quota 512), and finds that the OCS 504 is unavailable. In another embodiment the PGW 502 may identify unavailability of the OCS 504 based on its heartbeat. In response to unavailability of OCS 504, the PGW 502 automatically grants a default quota 511 such that the user equipment's service remains uninterrupted. Subsequent to the PGW 502' s granting of the default quota 511, the PGW 502 can delete the session 518, and the default quota usage can be written to a local charging data record (CDR) (i.e., an offline interface) which can be used to reconcile usage to the OCS or other system(s) as discussed above with respect to Figure 2.

[0047] In an embodiment a single system can perform all the techniques associated with Figures 1-5. For example, in an embodiment a single PGW can accommodate an OCS being non-responsive at any point in time. Alternatively, different systems may be implemented to perform each technique. In a further embodiment, a PGW may be configured to accommodate different types of OCSs that may or may not accept default quota reporting. Alternatively, a single PGW may be configured only to accommodate OCSs that either do or do not accept default reporting, but not both.

[0048] The techniques and systems disclosed herein are not limited to communications between a PGW and an OCS. For example, any component with policy and charging enforcement function (PCEF)/charging enforcement functionality could implement the techniques and systems disclosed herein. It should be appreciated that the techniques and systems disclosed herein could be implemented in existing network architecture (such as with a GSM/GPRS for 2G, GGSN for 3G, or other similar components in those releases or similar components/online charging nodes/charging enforcement nodes). A person having ordinary skill in the art would understand that the technique and systems disclosed herein would be applicable to future network architectures that have similar gateway/charging enforcement and online charging functionalities. [0049] While the techniques and systems disclosed herein have been described with respect to an online charging system, the invention could also be applied to an offline or other charging systems (e.g., GTP' or a GZ server). For example, a CDR can be used to reconcile usage when a GTP' is non-responsive.

[0050] The techniques and systems disclosed herein may be implemented with various types of subscribers. For example, a single subscriber could be associated with more than one user equipment. A subscriber thus may refer to the specific user equipment, or to the entire set of user equipment associated therewith. Each user equipment associated with an end user or an account could be treated as an individual subscriber. Additionally, a default quota may be assigned during a single session or across a plurality of sessions.

[0051] The techniques and systems disclosed herein may be implemented as a computer program product for use with a network, computer system or computerized electronic device. Such implementations may include a series of computer instructions, or logic, fixed either on a tangible medium, such as a computer readable medium (e.g., a diskette, CD-ROM, ROM, flash memory or other memory or fixed disk) or transmittable to a network, computer system or a device, via a modem or other interface device, such as a communications adapter connected to a network over a medium.

[0052] The medium may be either a tangible medium (e.g., optical or analog communications lines) or a medium implemented with wireless techniques (e.g., Wi-Fi, cellular, microwave, infrared or other transmission techniques). The series of computer instructions embodies at least part of the functionality described herein with respect to the system. Those skilled in the art should appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems.

[0053] Furthermore, such instructions may be stored in any tangible memory device, such as semiconductor, magnetic, optical or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, microwave, or other transmission technologies.

[0054] It is expected that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation (e.g., shrink wrapped software), preloaded with a computer system (e.g., on system ROM or fixed disk), or distributed from a server or electronic bulletin board over the network (e.g., the Internet or World Wide Web). Of course, some embodiments of the invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments of the invention are implemented as entirely hardware, or entirely software (e.g., a computer program product).

[0055] In the foregoing description, certain steps or processes can be performed on particular servers or as part of a particular engine. These descriptions are merely illustrative, as the specific steps can be performed on various hardware devices, including, but not limited to, server systems and/or mobile devices. Similarly, the division of where the particular steps are performed can vary, it being understood that no division or a different division is within the scope of the invention. Moreover, the use of "module" and/or other terms used to describe computer system processing is intended to be interchangeable and to represent logic or circuitry in which the functionality can be executed.