PCRF triggered rules cleanup

Various embodiments relate to a system and related method of handling a plurality of user messages originating from a user device in a communications network. Various embodiments relate to a Policy Charging and Rules Node (PCRN) receiving an initial message from a first device, while anticipating a complementary message from a second device. Upon receipt of the complementary message, the PCRN may pair the messages and generate a rule from the paired message. If the PCRN does not receive the complementary message, the PCRN may generate the rule from only the initially-received message or may ignore the message. The PCRN may treat each received message independent from each other so that lack of receipt of a complementary message does not affect the creation of rules from another paired message.

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 functionality. What was once a system designed solely for voice communications has recently grown into a heterogeneous system that enables access to communications platforms such as text messaging, multimedia streaming along with general Internet access. To support such applications, service and infrastructure providers have built new networks over existing voice communication infrastructure. As evidenced by second and third generation networks, voice services must be carried over dedicated voice channels toward a traditional circuit-switched core, while other services, such as IP-enabled data and communications may be transmitted over a different packet-switched core, following Internet protocol (IP). This has led to unique problems, including, for example, application provision, metering and charging, and quality of experience (QoE) assurance.

One recent attempt to enhance the dual-core approach of the second (2G, 2.5G) and third generations (3G) of mobile telecommunications standards defined by the International Telecommunications Union has been in the form of a new set of standards. The Third Generation Partnership Project (3GPP) has recommended a new network scheme deemed ‘Long Term Evolution’ (LTE). Under the new standards, all communications in an LTE network are carried over an IP channel from user equipment (UE), such as a mobile phone or smartphone, to an all-IP core named the Evolved Packet Core (EPC). The EPC may then provide gateway access to other networks, while also ensuring an acceptable QoE for a user's network activity and properly charging the subscriber for such activity.

The 3GPP generally describes the components of the EPC and their interactions with each other in some technical specifications, specifically, 3GPP TS 29.212, 3GPP TS 29.213, and 3GPP TS 29.214, which describe components such as a Policy and Charging Rules Function (PCRF), Policy and Charging Enforcement Function (PCEF), and Bearer Binding and Event Reporting Function (BBERF) of the EPC. These technical specifications also provided some details regarding the interactions between these components. These specifications gave some guidance on how the EPC could provide reliable data services to users, while also reliably charging subscribers for use of the IP network.

For example, 3GPP TS 29.212, 3GPP TS 29.213, and 3GPP TS 29.214 provide some guidance on rule generation by the PCRF when receiving messages from at least two different sources, such as, for example, the application function (AF) and the PCEF. These specifications provide some guidance, for example, for when the PCRN receives the first of a two-part message. However, the algorithm outlined by the specifications may not always work efficiently under certain circumstances.

In view of the foregoing, it would be desirable to provide a system and method more capable of handling complementary messages. In particular, it would be desirable to provide a system that may handle complementary messages for a range of circumstances.

SUMMARY

Various embodiments may relate to a method performed by a Policy Charging and Rules Node (PCRN) to handle a plurality of requests from a user device for service in a communications network. The method may include the PCRN receiving, from a first gateway, a plurality of initial requests to establish a plurality of services for the user device. The PCRN may then create a rule for each of the received initial requests in said plurality of initial requests and wait for a defined period to receive at least one complementary request from a second gateway, wherein each complementary request matches one of the received initial requests in the plurality of initial requests. The PCRN may then receive from the second gateway at least one complementary request, form at least one paired request after the defined period by matching each of the at least one received complementary request with one of the plurality of received initial requests, and remove each rule corresponding to each received request that is not part of the at least one paired request.

Various embodiments may also relate to a system for handling a plurality of requests from a user device for service in a communications network. The system may include the user device that requests a plurality of services. The system may also include a first gateway that transmits a plurality of initial requests to establish the plurality of services for the user device and a second gateway that transmits at least one complementary request to establish at least one service from the plurality of services for the user device, wherein the at least one complementary request matches at least one initial request from the plurality of requests. The system may also include a Policy and Charging Rules Node (PORN) that receives the plurality of initial requests and the at least one complementary request. The PORN in the system may create a rule for each of the plurality of initial requests received, wait for a defined period to receive the complementary requests, form at least one paired request after the defined period by matching each of the at least one complementary request with one of the plurality of received initial requests, and remove each rule corresponding to each received request that is not part of the at least one paired request.

It should be apparent that, in this manner, various exemplary embodiments enable dynamic handling of complementary messages from multiple sources. Particularly, by enabling the PCRN to control the handling of complementary messages, the PCRN may more efficiently process requests from a user device.

DETAILED DESCRIPTION

FIG. 1illustrates an exemplary subscriber network100for providing various data services. Exemplary subscriber network100may be a telecommunications network or other network for providing access to various services. Exemplary subscriber network100may include at least one piece of user equipment (UE)110, a base station120, an evolved packet core (EPC)130, a packet data network140, and an application node (AN)150.

User equipment (UE)110may be a device that communicates with the 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. Specifically, in various exemplary embodiments, UE110is a personal or laptop computer, wireless e-mail device, cellular phone, television set-top box, or any other device capable of communicating with other devices via the EPC130.

Base station120may be a device that enables communication between UE110and the EPC130. For example, the base station120may be a base transceiver station such as an evolved nodeB (eNodeB) as defined by 3GPP standards. Thus, the base station120may be a device that communicates with the UE110via a first medium, such as radio communication, and communicates with the EPC130via a second medium, such as an Ethernet cable. Base station120may be in direct communication with the EPC130or may communicate via a number of intermediate nodes (not shown inFIG. 1). In various embodiments, multiple base stations (not shown) similar to the base station120may be present to provide mobility to the UE110. In various alternative embodiments, UE110may communicate directly with the EPC130. In such embodiments, the base station120may not be present.

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

Serving gateway (SGW)132may be a device that provides gateway access to the EPC130. SGW132may be the first device within the EPC130that receives packets sent by the UE110. SGW132may forward such packets towards the PGW134. SGW132may perform a number of functions such as, for example, managing mobility of user equipment110between multiple base stations (not shown) and enforcing particular quality of service (QoS) characteristics, such as guaranteed bit rate, for each flow being served. In various implementations, such as those implementing the Proxy Mobile Internet Protocol (PMIP) standard, the SGW132may include a Bearer Binding and Event Reporting Function (BBERF). In various exemplary embodiments, the EPC140may include multiple SGWs (not shown) similar to the SGW132and each SGW may communicate with multiple base stations (not shown) similar to the base station120.

Packet data network gateway (PGW)134may be a device that provides gateway access to the packet data network140. PGW134may be the final device within the EPC130that receives packets sent by user equipment110toward the packet data network140via the 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, the PGW134may be a policy and charging enforcement node (PCEN). PGW134may 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 services, generates PCC rules, and provides PCC rules to the PGW134and/or other PCENs (not shown). PCRN136may be in communication with AN150via an Rx interface. PCRN136may receive requests from AN150, SGW132, or PGW134. Upon receipt of a service request, PCRN136may generate at least one new PCC rule for fulfilling the service request.

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 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.

PCRN136may receive related requests from a plurality of sources and may generate a PCC rule for fulfilling the service request related to the related requests. For example, a UE110may transmit a request for service. PCRN136may receive a first request from the AN150and a second, related request for service from the PGW134. PCRN136may pair the related requests together and generate a rule, e.g., a PCC rule, and send the generated rule to both the AN150and the PGW134

Subscription profile repository (SPR)138may be a device that stores information related to subscribers to the subscriber network100. Thus, SPR138may include a machine-readable storage medium such as a read-only memory (ROM), a random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and/or similar storage media. SPR138may be a component of PCRN136or may constitute an independent node within EPC130. Data stored by SPR138may include an identifier of each subscriber and indications of subscription information for each subscriber such as bandwidth limits, charging parameters, and subscriber priority.

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

Application node (AN)150may be a device that includes an application function (AF) and provides an application service to user equipment110. Thus, AN150may be a server or other device that provides, for example, a video streaming or a voice communication service to user equipment110. AN150may further be in communication with the PCRN136of the EPC130via an Rx interface. When AN150is to begin providing application service to user equipment110, AN150may generate a request message, such as an AA-Request (AAR) according to the Diameter protocol, to notify the PCRN136. This request message may include information such as an identification of the subscriber using the application service and an identification of the particular service data flows that must be established in order to provide the requested service. AN150may communicate such an application request to the PCRN136via the Rx interface.

FIG. 2illustrates an exemplary communications network, with a PCRN receiving multiple messages for a service request. System200is similar to system100, with application node (AN)201, policy and charging rules node (PCRN)202, packet data network gateway (PGW)203, user equipment204, and packet data network205corresponding to AN150, PCRN136, PGW134, UE110, and packet data network140, respectively.

In system200, UE204may send multiple related service requests through multiple devices, such as AN201and PGW203, with the request eventually being sent to PCRN202. PCRN202may then take the received service requests and form a plurality of services, using with the received information and other available information stored at the PCRN202. PCRN202may then implement the service and may also form associated rules, forwarding the created rules to PGW203, which may then transmit the rules to other gateways, such as SGW132.

UE204may, for example, send a session initiation protocol (SIP) service request that may be handled by application node (AN)201. AN201may receive the service request through packet data network205and PGW203. AN201may package the received service request into a message (MSG1) that may then be sent to the PCRN202via the Rx interface. The message sent by AN201may include information regarding connection details, such as the required bandwidth and type of media (e.g., voice, video, data, etc.) required. In some embodiments, the message sent by the AN201to the PCRN202may take precedent over messages the PCRN202receives from other components, so that when PCRN202receives conflicting messages from other components (e.g., PGW203), the PCRN202uses the information included in the message received from AN201.

The message sent by the AN201may be in the form of an AA-Request command. The AA-Request command may include a plurality of information, including the IP address of the UE204(for example, in a Forward-IP-Address attribute-value pair (AVP) or Framed-IPv6-Prefix AVP) and other service information (e.g., in a Media-Component-Description AVP). The AA-Request may also include information indicating the particular service to which a session may belong (for example, in an AF-Application-Identifier AVP).

UE204may also send another service request related to the SIP service request previously through the AN201. The related service request (e.g., complementary request) may be paired with the initial service request sent through the AN201. The complementary service request may be sent through the PGW203to the PCRN202, where the PGW203sends the complementary service request in the form of a CC Request message. PGW203may therefore send a message in that includes a CC Request. The CC Request may include an Event-Trigger AVP and a Packet-Filter-Operation AVP, which may trigger certain actions by the PCRN202, which will be discussed below in relation toFIG. 3. The CC Request may also include a corresponding Packet-Filter-Information AVP.

PGW203may include a policy charging and enforcement function (PCEF), which may include the complementary service request in a message (MSG2) that is sent to the PCRN202. The message sent from the PGW203may be the mate message to the message (MSG1) sent from the AN201, as the PCRN202may use information from both received messages (e.g., paired message) when creating a PCC rule. The information included in the message sent from PGW203may include other communication requirements, such as the required guaranteed bit rate. The information included in the message sent through the PGW203may be related to the requirements for the UE204to connect to the packet data network.

The PCRN202may receive one or messages containing information and may use the information to form at least one PCC rule. PCRN202may use different procedures to produce a rule based on the initial message it receives. For example, if the PGW203containing the PCEF solicits a request for the provisioning of the PCC rule, the PCRN202may implement a PUSH procedure, as will be discussed further in relation toFIG. 3, wherein the PCRN202provisions the PCC rule in a Re-authorization Request (RAR) command to the PGW203. Alternatively, when the request is unsolicited (e.g., the first request comes from AN201), the PCRN202may implement a PULL command, wherein PCRN202creates a PCC rule and includes the PCC rule in a CCA message.

The UE204may send one or more service requests simultaneously to the PCRN202. In some embodiments, the plurality of service requests may be for related services. In other embodiments, the UE204may request one or more unrelated services from the PCRN202. In some embodiments, the PCRN202may handle the plurality of service requests as completely unrelated and may handle the requests independent of each other. In other embodiments, the PCRN202may handle the plurality of service requests as related and may either enable or deny service based on the handling of each request in the plurality.

Having described the components of subscriber network100,200a brief summary of the operation of subscriber network100,200will be provided. It should be apparent that the following description is intended to provide an overview of the operation of subscriber network100,200and is therefore a simplification in some respects. The detailed operation of subscriber network100,200will be described in further detail below in connection withFIG. 3.

According to various exemplary embodiments, user equipment (UE)204may communicate with a plurality of devices, including the AN201, SGW132, or PGW203to indicate that user equipment204wishes to receive service. Such communication may occur via EPC130and packet data network205or via other communications channels (not shown). AN201, SGW132, or PGW203may then construct a message, including some of the necessary subscriber and data flow information necessary to provide the requested service. All of the necessary information may be scattered across multiple devices, such as the AN201, SGW132, SPR138, and the PGW203. AN201, SGW132, SPR138or PGW203may then forward the generated message to the PCRN202through the requisite interface.

Upon receipt of a first plurality of initial messages221-225, the PCRN202may wait for an equal quantity of complementary messages. In some embodiments, the PCRN202may wait for a defined period by starting a timer upon receipt of the first plurality of messages. In some embodiments, the PCRN's202initiation of the timer may move the creation of the rule to the end of an execution queue for the PCRN202. For example, PGW203may send a first plurality of initial messages221-225to the PCRN202, which may then anticipate receiving a second plurality of complementary messages231-233for each of the received initial messages221-225. The PCRN202may then place the generation of the PCC rule to the end of its execution queue, effectively waiting for the second plurality of complementary messages to arrive while executing other functions. When the PCRN202receives the second plurality of complementary messages231-233before the timer expires and the quantity of complementary messages is equal to the quantity of received initial messages, the PCRN202may immediately generate a quantity of rules equal to the plurality of initial messages221-225. PCRN202may use information from each set of paired messages (i.e., an initial message221and a complementary message231) to create each rule.

However, when the second plurality of complementary messages231-233does not completely arrive before the timer expires, the PCRN202may then generate a quantity of rules from the plurality of complete paired messages, i.e., initial messages221-223and complementary messages231-233. In some embodiments, the PCRN202may take no further actions for those received initial rules225for which the PCRN202did not also receive a complementary message. In some embodiments, the PCRN202may attempt to generate a rule using available information from at least the received initial message225. The PCRN202may also attempt to include information from existing rules. PCRN202may also take subscriber data from SPR138and internally-generated policy decisions into account when determining whether to attempt generating a rule from only the initial message225.

PCRN202may then transmit the generated PCC rule to PGW203via the Gx interface for installation. In some embodiments, the PCRN202may receive the missing complementary message (not shown) after the defined period. PCRN202may thereafter generate a new rule using both the initial message225and complementary message. The new rule may replace the previously-crafted rule that only used information from the initial message225. After installation of either the first or second rule, the PCRN202, through devices such as SGW132and PGW203, may therefore allow communication for the requested service, while also enabling further functionality by, for example, enabling the appropriate charging of the subscriber and ensuring that a particular QoS is met.

FIG. 3illustrates an exemplary flowchart for creating a new rule in response to a service request from the UE204. PCRN202may implement method300when it receives, for example, a service request from the UE204through the AN201and/or PGW203.

Method300may begin at step301and proceed to step303, where the PCRN202may receive a message from the UE204. In some embodiments, the PCRN202may receive a service request from AN201in the form of a service flow via the Rx interface. Because the PCRN202receives a message from the AN201first, the corresponding PCC rule may be labeled as “Network-Initiated.” The service flow may be derived from a hierarchy of components in an AN message. An AN message may consist of a plurality of Media Components (MC), with each Media Component containing a plurality of Media Sub-Components (MSC). Each Media Sub-Component may contain either one or two flow descriptions (FD). The service flow may be a flattened representation of this hierarchy, matching the one or two flow descriptions with the corresponding MCs and MSCs. Each service flow may map to a distinct rule that may be installed in the gateways SGW132or PGW134. Accordingly, the rule may contain a reference to the service flow used in its creation.

In another embodiment, the PCRN202may first receive a service request from PGW134that includes flow information. The flow information may be contained within a Packet-Filter-Information AVP included in the service request. The service request may also include a corresponding Packet-Filter-Operation AVP. In this instance, because the PGW134initiated the service request, the corresponding rule may be labeled as “UE-Initiated.” In some embodiments, the CC Request that comprised the service request may include a Packet-Filter-Information AVP for each packet filter requested by the UE204and a QoS-Information AVP that may indicate the requested quality of service for the packet filter.

Method300may then proceed to step305, where the PCRN202may determine whether it is storing a message that is a companion to the received message. In some embodiments, this may be an initially-received message or a created rule that matches the received service flow. In other embodiments, the companion message may be an initially-received service flow that matches the received flow information.

If there is a companion rule stored in the PCRN202, method300may proceed to step307, where the PCRN202may pair the received message with the stored companion message. PCRN202may create a paired message when combining the initially-received, stored companion message with the message received. In step309, the PCRN202may create a rule using information contained in the paired message. The information contained in the paired message may include all the information contained in both the initially received, the stored message, and the subsequently received message. In step311, the PCRN202may forward the new rule to the PCEF in PGW134, which may in turn push the new rule to other gateways. PCRN202may then end method300at step313.

If there is no companion message, this may indicate that the received message initiated the request for a rule, so the method proceeds to step321, where the PCRN202may wait for a defined period. PCRN202may start a timer to wait to receive the mate message. PCRN202may wait for the mate message because the mate message may contain information complementary to the initially-received message. For example, if the PCRN202initially received a message from AN201in step303, in step321, the PCRN202may wait for a defined period to receive a complementary message from PGW134.

PCRN202may wait until either the timer expires or the complementary message arrives. In either case, method300proceeds to step323-325, where the PCRN202determines if it received a message during the waiting period and if the newly-received message is complementary to the initially-received message. If the PCRN202did receive a complementary message, method300may then proceed to steps307-311, where the PCRN202binds the two messages into a paired message, creates a rule from the paired message, and pushes the newly-created rule to the gateways.

PCRN202may then proceed to step327, where it may determine whether the subscriber of the UE204has access to unknown services. In some embodiments, the PCRN202may determine whether the subscriber has access to unknown services through contact with the SPR138. If the subscriber does not have access to unknown services, method300may then proceed to step329. In this instance, the PCRN202may modify not generate a rule with the available information, which may only include the initially-received message. PCRN202may then end method300at step313.

Returning now to step327, if the PCRN202determines that the subscriber has access to unknown services, the PCRN202may generate rule using the information included in the PCRN202. In some embodiments, the PCRN202may generate a rule with only the information included in the initially-received message. In other embodiments, the PCRN202may use information from other stored services, such as information included in an associated unknown application. In some embodiments, the subscriber access to unknown services may be specific to the service. For example, the SPR138may hold records that state a subscriber has access to unknown voice services, but does not have access to unknown data services. After generating a new rule using available information, the PCRN202may proceed to step333, where it pushes the newly-generated rule to the PCEF in PGW134, which may then push the new rule to the other gateways. PCRN202may then end method300in step313.

During regular operation, the PCRN202may enact method300for each message received. In some embodiments, the PCRN202may therefore independently create rules for paired messages, while ignoring expected paired messages when the PCRN202receives only a portion of the pair. For example, if the PCRN202receives initial messages221-225, the PCRN202may wait to receive complementary messages231-235. When complementary messages231-233arrive, the PCRN202may enact method300for each received message to pair the subsequently-received messages231-233with initially-received messages221-223. As the PCRN202did not receive complementary message235(not shown), the PCRN202may not generate a rule for that message if the subscriber does not have access to unknown services.

Therefore, the PCRN202may handle the creation of rules independently, instead of, for example, dropping an entire bundle of messages if it did not receive complementary messages for each member of the bundle. This may save time and bandwidth, for example, as the PCRN202may only require the UE204to resend the missing pair of messages instead of the entire bundle. In some embodiments, the PCRN202may also save time and bandwidth by enabling the creation of a rule when a subscriber has access to unknown services and the PCRN202only receives a portion of an expected paired message.

According to the foregoing, various exemplary embodiments provide for dynamic creation of rules in response to the expected receipt of paired messages from multiple devices. Particularly, by independently generating rules upon receipt of initial and complementary messages and ignoring partially-received paired messages, the PCRN may enable proper functioning of the communications system, while also boosting efficiency and minimizing bandwidth.

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 another computing device. Thus, a machine-readable storage medium may include a read-only memory (ROM), a random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and similar storage media.