Method for PCRF to autonomously respond to cell capacity shortage

Various exemplary embodiments relate to a method and related network node and machine-readable storage medium including one or more of the following: determining network status; receiving an application request at the PCRN; generating a new PCC rule in response to the application request and network status; and providing the new PCC rule to a PCEN. Various exemplary embodiments further include receiving an event message, determining the network status from received event messages and isolating congestion using previously issued PCC rules and a network topology.

TECHNICAL FIELD

Various exemplary embodiments disclosed herein relate generally to policy and charging in telecommunications networks.

BACKGROUND

As the demand increases for varying types of applications within mobile telecommunications networks, service providers must constantly upgrade their systems in order to reliably provide this expanded demand. What was once a system designed simply for voice communication has grown into an all-purpose network, providing access to a myriad of applications that include combinations of text messaging, multimedia streaming, and general Internet access. As seen in second and third generation networks, voice services must be carried over dedicated voice channels and directed toward a circuit-switched core, while other services are transmitted via the Internet Protocol (IP) and directed to a different, packet-switched core. This led to unique problems regarding application provision, metering and charging, and quality of experience (QoE) assurance.

In an effort to simplify the dual core approach of the second and third generations, the 3rd Generation Partnership Project (3GPP) has recommended a new network scheme it calls Long Term Evolution (LTE). In an LTE network, all communications are carried over an IP channel from user equipment (UE) to an all-IP core called the Evolved Packet Core (EPC). The EPC then provides gateway access to other networks while ensuring an acceptable QoE and charging a subscriber for the QoS resources for their particular network activity.

The 3GPP describes the components of the EPC and their interactions with each other in a number of technical specifications. Specifically, 3GPP TS 29.212, 3GPP TS 29.213, and 3GPP TS 29.214, which are incorporated herein by reference, describe the Policy and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF), and Bearer Binding and Event Reporting Function (BBERF) of the EPC. These specifications further provide some guidance as to how these elements interact in order to provide reliable data services and charge subscribers for use thereof.

For example, 3GPP TS 29.212 provides guidance on the role of the PCRF in issuing policy and control charging (PCC) rules to the PCEF and Quality of Service (QoS) rules to the BBERF. 3GPP TS 29.212 specifies that the PCRF shall provide PCC and QoS rules in response to requests from the PCEF, the BBERF, or an Application Function (AF). The PCRF can use these rules to provision network resources in accordance with operator defined network policy. 3GPP TS 29.212 further specifies the format of requests and the provisioning of rules to the PCEF and BBERF. 3GPP TS 29.212 also specifies that there may be errors which prevent the PCEF or BBERF from successfully implementing rules provisioned by the PCRF. It specifies how the PCEF or BBERF should report these errors. 3GPP TS 29.212 also specifies the format for reporting other events such as termination of IP-CAN sessions and bearers.

The specifications describe several problems that may occur after the PCRF issues new rules. For example, the installation or activation of a new rule may fail because of a resource limitation or failure to allocate resources. Additionally, implementing new rules may cause the PCEF or BBERF to drop previous connections to free up resources for a higher priority connection, this is referred to as pre-emption. These types of errors result in a failure to provide service and subscriber frustration.

In view of the foregoing, it would be desirable to provide a more robust method of allocating resources. In particular, it would be desirable to provide a method for allocating resources while reducing the number of failures in installing or activating the rules and the number of dropped connections.

SUMMARY

In light of the present need for a method of allocating network resources that reduces failures and dropped connections, a brief summary of various exemplary embodiments is presented. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the various exemplary embodiments, but not to limit the scope of the invention. Detailed descriptions of a preferred exemplary embodiment adequate to allow those of ordinary skill in the art to make and use the inventive concepts will follow in later sections.

Various exemplary embodiments relate to a method performed by a Policy and Charging Rules Node (PCRN) for responding to a service request based on a status of a subscriber network, the method comprising: receiving at the PCRN a service request for resources controlled by the PCRN; determining the status of the subscriber network; determining from the status of the subscriber network whether the service request should be fulfilled as requested; if the service request should be fulfilled as requested, generating a new policy and charging control (PCC) rule to fulfill the service request; and if the service request should not be fulfilled as requested, modifying the service request and generating a new PCC rule to fulfill the modified service request or negotiation.

It should be apparent that, in this manner, various exemplary embodiments enable the allocation of network resources in response to the status of the subscriber network. In particular, by recording and analyzing data related to network events, a policy and rules charging node may determine the status of the network and issue new rules in response to the status of the network.

DETAILED DESCRIPTION

FIG. 1illustrates an exemplary subscriber network100for providing various data services. Exemplary subscriber network100may be telecommunications network or other network for providing access to various services. Exemplary network may include user equipment110, access network120, evolved packet core (EPC)130, packet data network140, and application function (AF)150.

User equipment110may be a device that communicates with packet data network140for providing the end-user with a data service. Such data service may include, for example, voice communication, text messaging, multimedia streaming, and Internet access. More specifically, in various exemplary embodiments, user equipment110is a personal or laptop computer, wireless email device, cell phone, smart phone, television set-top box, or any other device capable of communicating with other devices via IP over the EPC130.

Access network120may be a device or network of devices that enables communication between user equipment110and EPC130. For example, access network120may be a base transceiver station such as an evolved nodeB (eNodeB) as defined by 3GPP standards. Thus, access network120may be a device that communicates with user equipment110via a first medium, such as radio waves, and communicates with EPC130via a second medium, such as Ethernet cable. Access network120may be in direct communication with EPC130or may communicate via a number of intermediate nodes (not shown). In various embodiments, access network may include multiple base transceiver stations (not shown) to provide mobility to user equipment110. Note that in various alternative embodiments, user equipment110may communicate directly with evolved packet core130. In such embodiments, access network120may not be present.

Evolved packet core (EPC)130may be a device or network of devices that provides user equipment110with gateway access to packet data network140. EPC130may further charge a subscriber for use of provided data services and ensure that particular quality of service (QoS) standards are met. Thus, EPC130may be implemented, at least in part, according to the 3GPP TS 29.212, 29.213, and 29.214 standards. Accordingly, EPC130may include a serving gateway (SGW)132, a packet data network gateway (PGW)134, and a policy and charging rules node (PCRN).

Serving gateway (SGW)132may be a device that supports data paths between the access network120and PGW134. The data paths may contain virtual containers called bearers with unique Quality of Service (QoS) characteristics. The bearers may contain virtual connections called service data flows (SDFs). In various embodiments where user equipment110is a mobile device and access network120is an eNodeB, SGW132may be responsible for establishing new bearers when the mobile device changes eNodeB.

The SGW132may implement a bearer binding and event reporting function (BBERF) according to the 3GPP TS 29.212, 29.213, and 29.214 standards. The SGW132may also provide event messages to the PCRN136using the Gxx interface and credit control request (CCR) message170. SGW132may generate event messages to inform the PCRN136whenever there is any change in a bearer such as, for example, failure to allocate a bearer, termination of a bearer, preemption of a bearer or any other event trigger. SGW132may also request new QoS rules from the PCRN136by sending a CCR message via the Gxx interface.

Packet data network gateway (PGW)134may be a device that provides gateway access to packet data network140. PGW134may be the final device within the EPC130that receives packets sent by user equipment110toward packet data network140via SGW132. PGW134may include a policy and charging enforcement function (PCEF) that enforces policy and charging control (PCC) rules for each service data flow (SDF). Thus, PGW134may be a policy and charging enforcement node (PCEN). The PGW134may also provide event messages to the PCRN using the Gx interface and credit control response (CCR) message (not shown). PGW134may request new PCC rules from PCRN136by sending a CCR message via the Gx interface. PGW134may also include a number of additional features such as, for example, packet filtering, deep packet inspection, and subscriber charging support.

Policy and charging rules node (PCRN)136may be a device that receives requests for application services, generates PCC rules, and provides PCC rules to the PGW134and/or other PCENs (not shown). In various embodiments, PCRN136may also provide QoS rules to the SGW. PCRN136may be in communication with AF150via an Rx interface.

PCRN136may also be in communication with SGW132and PGW134via a Gxx and a Gx interface, respectively. Upon creating a new PCC rule or upon request by the PGW134, PCRN136may provide a PCC rule to PGW134via the Gx interface. In various embodiments, such as those implementing the Proxy Mobile IP (PMIP) standard for example, PCRN136may also generate QoS rules. Upon creating a new QoS rule or upon request by the SGW132, PCRN136may provide a QoS rule to SGW132via the Gxx interface.

Packet data network140may be any network for providing data communications between user equipment110and other devices connected to packet data network140, such as AF150. Further, Packet data network140may provide, for example, phone and/or Internet service to various user devices in communication with packet data network140.

Application function (AF)150may be a device that provides an application service to user equipment110. Thus, AF150may be a server or other device that provides, for example, streaming video service to user equipment110. AF150may further be in communication with the PCRN136of the EPC130via an Rx interface. When AF150is to begin providing application service to user equipment110, AF150may generate an application request message, such as an AA-Request (AAR)160according to the Diameter protocol and/or 3GPP TS 29.214, to notify the PCRN136that resources should be allocated for the application service. Such application request message may include information such as an identification of the subscriber or its IP address using the application service and an identification of the particular service data flows that must be established in order to provide the requested service. AF150may communicate such an application request to the PCRN via the Rx interface.

Having described the components of subscriber network100, a brief summary of the operation of subscriber network100will be provided. It should be apparent that the following description is intended to provide an overview of the operation of subscriber network100and is therefore a simplification in some respects. The detailed operation of subscriber network100will be described in further detail below in connection withFIGS. 2-5.

According to various exemplary embodiments, PCRN136may receive requests to allocate resources from AF150, SGW132or PGW134. PCRN136may allocate resources by generating appropriate PCC and QoS rules and send them to PGW134and SGW132. Once PCC and QoS rules are installed in the PGW134and SGW132respectively, these components may be responsible for monitoring network connections. When an event occurs which affects bearer state the PGW134or SGW132may report the event to the PCRN136using a message such as, for example, CCR170. For example, if the SGW132detects an error in installing a new QoS rule or allocating a new bearer, SGW132may send CCR170to the PCRN136providing details of the event. It should be noted that other types of messages may be used to report events in various circumstances. Events may not be limited to errors and may include any event for which PCRN136provisioned an event trigger to SGW132or PGW134and events which do not require any event trigger. PCRN136may process the information provided in event messages along with other information to determine the status of the subscriber network. The PCRN136may then take the network status into account when making policy decisions. For example, if the PCRN136determines that a requested network resource is scarce (i.e., there is a high likelihood of being unavailable), it may deny a new resource request. The PCRN136may also negotiate with the AF150based on the network status. For example, if the PCRN136determines that an application request with a low QoS is likely to be dropped or if assigned it would perform poorly (for non-guaranteed bearers), it may inform the AF150that a higher QoS is required. If the higher QoS is acceptable, AF150may then send a new application request. As another example, if PCRN136determines that an application request with a high QoS is likely to pre-empt existing services, it may inform the AF150that a lower QoS is available at a lower charging rate. If the lower QoS is acceptable, AF150may send a new application request.

FIG. 2illustrates an exemplary policy and charging rules node (PCRN)200for creating new policy and charging control (PCC) and quality of service (QoS) rules at least partially based on network status. PCRN200may correspond to PCRN136of exemplary subscriber network100. PCRN200may include Gxx interface205, Gx interface210, Event Recorder215, Event Storage220, Rule Storage225, Network Topology230, Rx interface235, Application Request Translator240, Network Status Analyzer245, Network Status Modifier250, and Rule Generator255.

Gxx interface205may be an interface comprising hardware and/or executable instructions encoded on a machine-readable storage medium configured to communicate with an SGW such as SGW132. Such communication may be implemented according to the 3GPP TS 29.212. Specifically, Gxx interface205may receive event messages and application requests from SGW132and send QoS rules to SGW132using Gxx interface205.

Gx interface210may be an interface comprising hardware and/or executable instructions encoded on a machine-readable storage medium configured to communicate with a PGW such as PGW134. Such communication may be implemented according to the 3GPP TS 29.212. Specifically, Gx interface210may receive event messages and application requests from PGW134and send PCC rules to PGW134using Gx interface210.

Event Recorder215may include hardware and/or executable instructions on a machine-readable storage medium configured to process incoming event messages and record data in Event Storage230. Event Recorder215may receive event messages over Gx interface210and/or Gxx interface205. Next, Event Recorder215may extract event data from the event message. Event Recorder215may then add additional information such as an event ID and time to the event data. The Event Recorder215may then pass the event data to Event Storage220for recording.

Event Storage220may be any machine-readable medium capable of storing event data generated by the Event Recorder215. Accordingly, Event Storage220may include a machine-readable storage medium such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and/or similar storage media. As will be described in further detail below with respect toFIG. 4, Event Storage220may store data regarding numerous types of events reported to PCRN200. Such data may include, for example, type of event, affected PCC rule, affected data flows, QCI of affected flows, allocation retention priority (ARP) of affected flows, subscriber identification, eNodeB, serving gateway and time of event. Rule Storage225may be any machine-readable medium capable of storing PCC rules generated by Rule Generator255. Accordingly, Rule Storage225may include a machine-readable storage medium such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and/or similar storage media. Rule Storage225may store definitions of numerous PCC rules created by Rule Generator255. Such definitions may include, for example, rule names, service data flow filters, QoS parameters, and charging parameters. Rules Storage225may use any manner known in the art to store PCC rules and update rule data.

Network Topology230may be any machine-readable medium capable of storing data representing the components of subscriber network100. Accordingly, Network Topology230may include a machine-readable storage medium such as read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and/or similar storage media. Network Topology230may be built dynamically or by using information provisioned from a management system or by any other method known in the art.

Rx interface235may be an interface comprising hardware and/or executable instructions encoded on a machine-readable storage medium configured to communicate with an AF such as AF150. Such communication may be implemented according to the 3GPP TS 29.214. Specifically, Rx interface235may receive an application request from AF150and respond to an application request via the Rx interface.

Application Request Translator240may include hardware and/or executable instructions on a machine-readable storage medium configured to determine from an application request received via Gxx interface205, Gxx interface210or Rx interface235what service data flows will be necessary to provide the requested service. Application Request Translator240may then generate a service request object to represent the requested service data flows. Application Request Translator240may then pass the service request object to Network Status Analyzer245for further processing.

Network Status Analyzer245may include hardware and/or executable instructions on a machine-readable storage medium configured to determine whether PCRN200should fulfill a service request based on the status of the required network resources. Network Status Analyzer245may use data stored in Event Storage220, Rule Storage225and/or Network Topology230to determine the status of the subscriber network. Using this data, the Network Status Analyzer245may determine that a requested resource is congested or that a requested QoS Class Identifier (QCI) is likely to be preempted; therefore, the service request should not be fulfilled. If Network Status Analyzer245determines that PCRN200should not fulfill a service request, it may pass the failed service request to Network Status Modifier250for further processing. If Network Status Analyzer245determines that PCRN200should fulfill a service request, it may pass the service request to Rule Generator255for further processing.

Network Status Modifier250may include hardware and/or executable instructions on a machine-readable storage medium configured to receive a denied service request from Network Status Analyzer245and negotiate with AF150over Rx interface235for an updated application request. Network Status Modifier250may consider the requested service flows and the reason the service request was denied in order to determine whether an upgrade or downgrade may be applicable according to provider encoded rules in the PCRN. Network Status Modifier250may then determine an acceptable service request. Network Status Modifier250may then propose the acceptable service request to AF150over Rx interface205using an AA-Answer (AAA) message (not shown). In various embodiments, Network Status Modifier250may also negotiate with SGW132or PGW134if the application request comes in the form of a CCR request. In this scenario, Network Status Modifier250may propose the acceptable service request to SGW132or PGW134via the Gxx interface205or Gx interface210, respectively, using a CC-Answer (CCA) message (not shown).

Rule Generator255may include hardware and/or executable instructions on a machine-readable storage medium configured to generate new PCC and/or QoS rules based on a received service request. Rule Generator255may generate PCC and/or QoS rules according to any method known to those of skill in the art.

FIG. 3illustrates an exemplary event message300. Event message300may be a CCR message constructed according to the Diameter message protocol and/or 3GPP TS 29.212. Accordingly, event message300may include a header310, subscription ID field330, AN-GW-Address field340, Event-Trigger field350, Rule-Report field360and a number of additional fields320,370. Note that the order of the fields of CCR300may vary. Thus, for example, subscription ID field330may be located after AN-GW-Address field340or Rule-Report Field360.

Header310may be a standard Diameter header indicating that message300is a CCR. Thus, header310may include a command code field set to a value of 272 and the R-bit field of the command flags field set, as provided for by the Diameter protocol and 3GPP TS 29.212.

Subscription ID field330may be an attribute-value pair (AVP) for indicating the subscriber that is associated with a particular event message. For example, subscription ID field330indicates that the subscription identified as “123456789012345” is associated with CCR300. This information may be used to identify the particular phone or user affected by the event.

AN-GW-Address field340may be an AVP for indicating the SGW that is associated with a particular event message. AN-GW-Address field340may store an IPv4, IPv6 address, or any other identifier known in the art of identifying a network device. For example, AN-GW-Address field340indicates that the SGW identified as “0x7374” is associated with the event.

Event-Trigger field350may be an AVP for indicating the type of event which caused the event message. For example, Event-Trigger field350indicates that the event is a loss of bearer, as indicated by the LOSS_OF_BEARER enumerated value. The type of event may also determine, at least in part, which additional fields320,370are included in the event message.

Rule-Report field360may be an AVP for indicating any changes in QoS or PCC rules. Rule-Report field360may include QoS information related to the event. This may include the QoS Class Identifier (QCI)363, maximum upload and download bandwidth (not shown), guaranteed upload and download bitrates (not shown), bearer identifier (not shown) and allocation retention priority (ARP)366.

Additional fields320,370may include additional information as specified by the Diameter protocol and/or any 3GPP standard. Thus, additional fields320,360may include additional AVPs such as, for example, the Origin-Host AVP, Destination-Host AVP, Supported-Features AVP, Framed-IP-Address AVP, etc. Event Recorder215may use additional fields320,260for extracting other useful information such as, for example, flow identifying information. The person of ordinary skill in the art will recognize that relevant event data may vary greatly, affecting the content of event message300.

FIG. 4illustrates an exemplary data arrangement400for storing event data. Data arrangement400may be, for example, a table in a database stored in Event Storage225. Alternatively, data arrangement400could be a series of linked lists, an array, or a similar data structure. Thus, it should be apparent that data arrangement400is an abstraction of the underlying data; any data structure suitable for storage of this data may be used.

Data arrangement400may include an Event ID field405, a Time field410, a Subscriber ID field415, an eNodeB ID420, an SGW ID field425, an Event Trigger field430, a QCI field435, an ARP field440and a PCC rule field445. Data arrangement400may include additional fields (not shown) required or useful in defining event data. Data arrangement400may include multiple entries such as, for example, entries450,455and460.

Event ID field405may be used to uniquely identify each event. Time field410may be used to indicate the time of the event. Any method known in the art such as, for example, NTP may be used to indicate the time of the event. Subscriber ID field415may be used to identify the subscriber or user device affected by the event. SGW ID field420may be used to indicate the SGW that reported the event. In various embodiments, the 3GPP-USER-LOCATION-INFO AVP may also be used to provide a finer location. Event Trigger field425may be used to store the type of event. QCI field420may be used to store the QCI of the data flow associated with the event. ARP field435may be used to store the ARP of the data flow associated with the event. eNodeB ID field440may be used to indicate the eNodeB that was servicing the subscriber at the time of the event. PCC rule field445may indicate a PCC rule to which the event relates.

As an example, record450indicates that the event represented by Event ID “36” occurred at time “1111111112”. This event affected a service flow which was being used by a subscriber identified by subscriber ID “234567890123456” and was using an eNodeB identified by eNodeB ID “0x5FCC” and an SGW identified by SGW ID “0xB832”. The event is of type “LOSS_OF_BEARER” indicating that a bearer was dropped. At the time of the event, the service flow had a QCI of 2 and an ARP of 5. The event affected a PCC rule identified by “0x3B72”.

As another example, record455indicates that the event represented by Event ID “40” occurred at time “1111111114.” This event affected a service flow which was being used by a subscriber identified by subscriber ID “345678901234567” and was using an eNodeB identified by eNodeB ID “0x6031” and a SGW identified by SGW ID “0xB832”. The event is of type “LOSS_OF_BEARER” indicated that a bearer was dropped. At the time of the event, the service flow had a QCI of 3 and an ARP of 3. The event affected a PCC rule identified by “0x82A3”

FIG. 5illustrates an exemplary method500for creating new policy and charging control (PCC) rules at least partially based on the status of subscriber network100. Method500may be performed by the components of PCRN136and/or PCRN200to establish PCC rules for service data flows in response to the status of the subscriber network.

Method500may begin at step505and proceed to step510where PCRN200receives an event message over Gxx interface205or Gx interface210. Method500may then proceed to step515where Event Recorder215may process the event message by extracting event information. Event Recorder215may then add information such as an Event ID and the time of the message. Event Recorder may then enter the event information into Event Storage220.

Method500may then proceed to step520where PCRN receives an application request from an AF via the Rx interface205. Method500may then proceed to step525where Application Request Translator240may translate the request into a service request object containing service flow objects.

Then, at step525, the Network Status Analyzer245may determine the network resources required to fulfill the service request. This step may require the Network Status Analyzer245to access the Network Topology to determine which network resources would be used to create each service flow of the service request. Method500may then proceed to step525where the Network Status Analyzer245may determine the status of the requested resource. Network Status Analyzer245may analyze the status of the requested resources by using the data in Event Storage220, Rule Storage225, and/or Network Topology230. Network Status Analyzer245may search the Event Storage220for event data relating to a required network resource. If the Event Storage220indicates a statistical trend in the event data related to a particular resource, the Network Status Analyzer245may determine that the network resources are congested, unavailable, or otherwise not suited to provide the requested services. For example, if the Network Status Analyzer245finds a commonality such as multiple events with the same SGW ID field420and the Event Trigger Field425indicates a LOSS_OF_BEARER, the Network Status Analyzer may be able to determine that the indicated SGW or more specifically, a subtending eNodeB is congested. The Network Status Analyzer245may also cross-reference the event data with rule data in Rules Storage225when searching for statistical trends using PCC rule field445. The Network Status Analyzer245may use the Network Topology230to isolate congestion if more than one network resource appears congested. It should be appreciated that this is only one example of a statistical trend. The person of ordinary skill of the art will recognize that many possible statistical trends among the data in Event Storage220, Rule Storage225, and Network Topology230may indicate the status of the subscriber network.

Method500may then proceed to step535where the Network Status Analyzer245may determine whether the service request should be fulfilled. The Network Status Analyzer245may consider the status of the subscriber network as well as internal policy controls. If the service request should not be fulfilled because of the network status, method500may proceed to step540. If the service request should be fulfilled, method500may proceed to step550.

In step540, Network Status Modifier250may determine an allowable service request. For example, Network Status Modifier250may require a higher ARP if the Network Status Analyzer245determines that required resources are congested and likely to drop low priority service flows. Method500may then proceed to step545where the Network Status Modifier250responds to the application request of the AF150. Network Status Modifier250may use an AA Answer (AAA) command to indicate that the previous request will not be fulfilled and to propose an allowable application request. If the AF150accepts the proposed application request, it may modify and transmit the application request. Then, method500will return to step520.

In step550, the Rule Generator255may generate PCC rules to implement the service request. The Rule Generator255may combine information provided in the application request with internal policy decisions to create PCC rules. Rule Generator255may then transmit the new PCC rules to PGW134via the Gx interface210. The PCRN may also add the PCC rule to Rules Storage225at this point.

At step555, Rule Generator255may generate QoS rules from the PCC rules by extracting the QoS portion. Rule Generator255may then transmit the QoS rules to SGW via the Gxx interface and method500may end in step560.

Having described exemplary components and methods for the operation of exemplary subscriber network100and PCRN200, an example of the operation of exemplary network100and PCRN200will now be provided with reference toFIGS. 1-5. PCRN136may correspond to PCRN200. The contents of Event Storage220may be indicated by data arrangement400. CCR170may be described in detail by CCR300.

The process may begin when PCRN136,200receives CCR170,300from SGW132. Event Recorder215may then process the fields of CCR170to extract event data. Event Recorder215would extract a Subscriber ID of “0xA9B6” from the Subscriber-ID AVP330, a SGW ID of “0x7374” from AN-GW-Address340, an Event Trigger of “LOSS_OF_BEARER” from Event-Trigger AVP350, a QCI of 3 from QoS-Class-Identifier AVP363and an ARP of 3 from Allocation-Retention-Priority AVP366. Event Recorder215may provide other event data such as an Event ID of 0x43BA and a Time of 43. Event Recorder215may then create a new event data record in Event Storage220.

Rx interface205may then receive an AAR160containing an application request from AF150. Application Request Translator240may then translate the application request into a service request containing one or more service flows. Network Status Analyzer245may then determine that the service request requires several resources including SGW 0xB832. Network Status Analyzer may then search Event Storage220and Rules Storage225for data records containing SGW 0xB832. From the data in data arrangement400, Network Status Analyzer may determine that SGW 0xB832 is experiencing congestion for a particular resource class because it contains multiple events indicating a loss of bearer (correlated to the resource class) for that SGW within a short time period.

In step530, the Network Status Analyzer may determine that the service request should not be fulfilled because, for instance, the ARP is low and the SGW is likely drop the bearer quickly. Therefore, the method will proceed to step535where the Network Status Modifier250may determine an allowable application request. Network Status Modifier may determine that a higher ARP will prevent dropping the bearer. Network Status Modifier, in step540, may then send to AF150, via Rx interface205, an AAA indicating that an application request with a higher QoS will be allowable. If AF150agrees to raise the requested QoS, the AF may send another application request. A QoS upgrade or downgrade may involve changes to QCI, ARP or Bandwidth.

The method will proceed as before from step515until step530, where the Network Status Analyzer may determine that it should allow the service request. In step545, the Rule Generator may then generate a PCC rule from the service request and internal policy decisions. The new PCC rule may be stored in Rule Storage225. In step560, the Rule Generator may transmit the new PCC rule to PGW134via Gx interface210. If Gateway Control Sessions exist, the Rule Generator may generate a QoS Rule from the PCC rule and transmit the QoS rule to SGW132via Gxx interface205.

According to the foregoing, various exemplary embodiments provide for creation of PCC rules in response to the status of a subscriber network. In particular, by recording events related to previously implemented PCC and QoS rules, a policy and charging rules node may generate new rules which are responsive to the status of the subscriber network.

It should be apparent from the foregoing description that various exemplary embodiments of the invention may be implemented in hardware and/or firmware. Furthermore, various exemplary embodiments may be implemented as instructions stored on a machine-readable storage medium, which may be read and executed by at least one processor to perform the operations described in detail herein. A machine-readable storage medium may include any mechanism for storing information in a form readable by a machine, such as a personal or laptop computer, a server, or other computing device. Thus, a machine-readable storage medium may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and similar storage media.